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Preface 



This publication is intended for system 
programmers and those responsible for the 
planning and installation of a VM/37Q 
system. It contains information about 
VM/370 and the procedures used to generate 
and support a VM/370 system. 



of System/370 data processing techniques 
and be familiar with teleprocessing 
techniques. 



This publication has six parts, plus 
Appendixes. 

"Part 1 : Planning for System Generation" 
describes the components, features, and 
options of VM/370, and tells you what you 
must do during system generation to support 
them. Part 1 includes information about 
CMS, RSCS, and other operating systems in a 
virtual machine. It also discusses 
performance options, saved systems, 
minidisks, and lists the devices supported 
by VM/370. 

"Part 2: Defining Your VM/370 System" 
tells you how to create the files that 
define your system. The real I/O 
configuration (DMKBIO) , CP system control 
(DMKSYS) , VM/370 Directory (DMKDIR) , system 
name table (DMKSNT) , and forms control 
buffer load (DMKFCB) files, and the macros 
and control statements needed to create 
them, are described. 

"Part 3: Generating VM/370 (CP, CMS and 
RSCS)" describes the step-by-step procedure 
for installing CP, CMS, and optionally 
RSCS. The three starter systems for CP and 
CMS (2314, 3330, and 3340) are discussed 
separately. Also included is a description 
of the Installation Verification Procedure 
(IVP) for CP and CMS. 

"Part 4: Generating the 3704/3705 
Control Program" describes the step-by-step 
procedure for installing a 3704/3705 
control program that runs under VM/370. 

"Part 5: The Standalone Spool Remote 
Program" describes the installation 
procedure for the 2780 Spool Remote Program 
(DMKSRP) . 

"Part 6: Updating VM/370" describes the 

procedures, programs, and EXEC procedures 

to update VM/370 source code and macro 
libraries. 



The appendixes include information 
about : 

The program products supported by CMS 

Configuring VM/370 

Representative VM/370 directory entries 

CMS regeneration requirements 

Notational conventions for commands and 
macros 

Service programs 

Compatibility between VM/370 and CP-67 

The procedure for generating a 3340 
system residence volume from a current 
2314/3330 system residence volume and 
the Program Level Change (PLC) tape 

I • VM/370 restrictions 

An expanded glossary is available in the 
ISH XiliJSSl Machine Faci li t j/3 7 : Glossary 
and Master Index, Order No. GC20-1813. 

In this publication, the following terms 
have extended meanings: 

• The term 3330 refers to the IBM 3330 
Disk Storage, Model 1, 2, or 11, or the 
IBM 3333 Disk Storage and Control, Model 
1 or 11. 

• The term 2305 refers to the IBM 2305 
Fixed Head Storage, Models 1 and 2. 

I • The term 3270 refers to the IBM 3275 and 
I 3277 Display Stations. 

• The term "typewriter terminal" refers to 
printer-keyboard devices that produce 
hard-copy output only (such as the IBM 
2741 Communication Terminal, the IBM 
3215 Console Printer-Keyboard, or the 
IBM 3767 Communication Terminal, Model 1 
or 2, operating as a 2741). 

• The term 2741 refers to the IBM 2741 
Communcation Terminal, and also the 3767 
Communication Terminal (unless otherwise 
noted) . 

• The term "display device" refers to 
system consoles and terminals that 
display data on a screen (such as the 
IBM 3066 System Console or the IBM 3277 
Display Station) . 
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Onless otherwise noted, where the tern 
"Attention key" is used in this 
publication, the phrase "(or 
equivalent)" is iaplied. The equivalent 
key on the 1050 terminal is the RESET 
LIHE key; on the 3277 terminal, the 
Enter key. Each of the terminals that 
can be used with the VM/370 system has a 
key that is the equivalent of the 
Attention key on the 2741 (with which 
you can signal an attention interrupt) . 



COREQOISITE PUBLICATIONS 



IBM Virtual Machine Facility/37 : 

Command Language Guide for General 
Users, Order Mo. GC20-180U 

0Eei§.iO£ls Guide, Order No. GC20-1806 

System Programmer's Guide, Order No. 
GC20-1807 

System Messages, Order No. GC20-1808 

T§£linal Oser^s Guide, Order No. 
GC20-1810 



l§12i§ §E22iiSa Communications Subsystem 
(BSCS) Oserls Guide, Order No. GC20-1816 



Release 2 Guide, Order No. GC20-1815 



Introduction to the IBM 3704 and 3705 
Communications Controllers, Order No. 
GA27-3051 

IM 370U and 3705 Communications 

Controllers, Network Control Proqram/VS 
Generation and fitilities Guide and 
Refergncg Manual (for OS/VS TCAM Users) , 
Order No. GC30-3007 

IBM 3704 and 3705 Communications 
Controllers, Network C o ntrol Program/VS 
Generation and Utilities, Guide and 
Sef erince Manual (for OS/VS and DO S/VS VTAM 
Osers) , Order No. GC30-3008 



IBM 3704 Control 
GA27-3086 



Panel Guide, Order No. 



IBM 3705 Control Panel Guide, Order No. 
GA27-3087 

IBM OS/VS Linkage Ed itor and Loader, Order 
No. GC26-3813 

IBM 2780 Data Transmission Terminal -- 
Component Description, Order No. GA27-3005 



Figure 1 is an overview of the VM/370 
library, with the publications grouped 
according to their probable users. 



References in the text to titles of 
prerequisite and corequisite VM/370 
publications will be given in abbreviated 
form. 



Virtual Machine Facility/370 (VIW370) Library 

(Release 2 PLC 11) 
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VM/370; Glossary and 
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GC20-1813 
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Support 
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VM/370; Terminal 
User's Guide 

GC20-1810 








VM/370; Command 
Language Guide for 
General Users 

GC20-1804 






VM/370; OLTSEPand 
Error Recording Guide 

GC20-1809 
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System Programming 








VIVI/370: EDIT Guide 
GC20-1805 
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VM/370; Control 
Program (CPI 
Program Logic 

SY20-0880 


























VM/370; Operator's 
Guide 

GC20-1806 






VM/370; Release 2 
Guide 

GC20-1815 












VIVI/370: EXEC User's 
Guide 

GC20-1812 
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VM/370: Conversational 
Monitor System (CMS) 
Program Logic 

SY20-0881 














VM/370 Planning and 
System Generation 
Guide 
GC20-1801 






RSCS Users 






OS/VS, DOS/VS, and 
VIVI/370 Assembler 
Language 

GC33-4010 
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VM/370; Remote Spooling 
Communications Subsystem 
(RSCS) Users' Guide 

GC20 1816 




VM/370; System 
Programmer's Guide 

GC20-1807 




VM/370: Service 
Routines Program 
Logic 

SY20-0882 




OS/VS and VIVI/370 
Assembler Programmer's 
Guide 

GC33-4021 
















































VM/370; Remote Spooling 
Communications 
Subsystem (RSCS) 
Program Logic 
SY20-0883 
































VM/370; System 
Messages 

GC20-1808 




















OS/VS and VM/370 
Assembler Program 
Logic 

SY33-8041 










If both of these 
documents are 




VM/370; Ouick Guide for 
Users Reference Summary 

GX20-1926 








please use: 

GBOF3576 






VM/370; Summary of 
Commands 

GX20-1961 







Figure 1. Virtual Machine Facility/370 Library 
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Sunmary of Amendments 

for GC20-18G1-'i 

as updated by GN20-2658 

VM/370 Release 2 PLC 13 



VM/370 MEASUREMENT FACILITY 



New; Program Feature 

The VM/370 control program has two 
commands that measure system 
performance: INDICATE and MONITOR. The 
INDICATE command is new; the function of 
the MONITOR command is expanded. A new 
section, "Performance Measurement and 
Analysis," is added to "Part 1: 
Planning for System Generation" to 
reflect this new support. 



VM/VS HANDSHAKING FEATURE 



New: Program Feature 

The VM/VS Handshaking f 
communication path between 
0S/VS1 that makes each sy 
program aware of certain 
and requirements of the 
"Multiprogramming Systems 
section of "Part 1: Planni 
Generation" is updated to 
new programming feature* 



eature is a 
VM/370 and 

stem control 
capabilities 
other. The 

Under VM/370" 

ng for System 
reflect this 



A new section, "Planning 
Considerations for Remote 3270s," is 
included in "Part 1: Planning for 

The "Estimating VM/370 Storage 
Requirements" section of "Part 1 : 
Planning for System Generation" is 
updated. 

The "Configurations" section of "Part 
1 : Planning for system Generation" 
is updated. 

The "Preparing the Real I/O 
Configuration File (DMKRIO)" section 
of "Part 2: Defining Your VM/370 
System" is updated. Descriptions of 
the two new macros, CLUSTER and 
TERMINAL, are included. 

"Part U: Generating the 3704/3705 
Control Program" is updated. 



"Appendix B: 
updated. 



Configuration Aid" is 



"Appendix I: VM/370 Restrictions" 
contains changes for remote 3270 
support. 



REMOTE 3270 SUPPORT 



MISCELLANEOUS CHANGES 



New: Program Feature 

VM/370 now supports the 3270 Display 
System as a remote virtual machine 
console attached via nonswitched 
point-to-point binary synchronous lines 
to a 2701 Data Adapter Unit or 2703 
Transmission Control Unit. Remote 3270s 
are also supported on 3704/3705 lines in 
emulation mode. A 3704/3705 is in 
emulation mode if it is controlled by 
the Emulation Program (EP) or the 
Partitioned Emulation Program (PEP) in 
EP mode. 



The following changes to 
publication reflect this support: 



this 



The "CMS Planning Considerations" 
section of "Part 1: Planning for 
System Generation" is updated. 



Changed; Program and Documentation 

Numerous small changes have been made 
to this publication. In addition, the 
following changes were made: 

• The restriction about using the 
Virtual Machine Assist Feature with 
dedicated channels no longer 
exists. The "Virtual Machine 
Assist Feature" section of "Part 1: 
Planning for System Generation" is 
updated. 

• The "Estimating VM/370 Storage 
Requirements" section of "Part 1: 
Planning for System Generation" is 
updated. 

• The "Minidisks" section of "Part 1: 
Planning for System Generation" is 
updated. 
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Corrections have been made to the 
"Configurations" section of "Part 
1: Planning for System 
Generation". 

Corrections have been aade to the 
"HDEVICE Macro" section of "Part 2: 
Defining Your VM/370 System." 

The "RCTLUHIT Macro" section of 
"Part 2: Defining Your VM/370 
System" is updated. 

Changes have been made to the 

OPTION, SPOOL, DEDICATE, and 

SPECIAL control statements of the 

Directory program in "Part 2: 
Defining Your VM/370 System." 

Minor changes have been made to 
Steps 12 and 17 of the 231U, 3330, 
and 33U0 Starter System 



descriptions in 
Generating VM/370 
RSCS) . " 



"Part 
(CP, CMS, 



3: 
and 



'Part U: Generating the 3704/3705 
Control Program" is updated to show 
the publications needed for Version 
3 of the 3704/3705 control 
program. 

"The Loader" section of "Part 6: 
Updating VM/370" is updated to show 
you how to update the loader and 
create an executable form of the 
updated loader. 

A new appendix, "Appendix I: VM/370 
Restrictions," is included in this 
publication. This information was 
previously in the VM/370: 
Introduction. 



Summary of Amendments 

for GC20- 1801-4 

VM/370 Release 2 PLC 11 



PUBLICATION REWRITTEN 



New: Documentation 



The VMZ370: Planning and Sjstem 
Generation Guide is completely rewritten 
and reorganized. Information that did 
not pertain to system generation is no 
longer in this publication. The 
information in "Section 2. CMS 
Considerations" and "Section 3. 
Operating Systems — General 
Information" that did not pertain to 
system generation was moved to the 
Yi?Z370 : Comman d Language Guide for 
General Users. 



The revised Y 11^370: Planning and 
System Generation Guide has six parts 
and eight appendixes: 



"Part 1 : Planning 
Generation" 



for System 



"Part 2: Defining Your VM/370 System" 

"Part 3: Generating VM/370 (CP, CMS, 
and RSCS)" 

"Part 4: Generating the 3704/3705 
Control Program" 

"Part 5: The Standalone Spool Remote 
Program" 

"Part 6: Updating VM/370" 

"Appendix A: IBM Programs Executable 

Under CMS" 

"Appendix B: Configuration Aid" 

"Appendix C: Representative Directory 
Entries" 

"Appendix D: CP/CMS Nucleus/Module 
Regeneration Requirements" 

"Appendix E: Hotational Conventions" 

"Appendix F: VM/370 Service Programs 
Used During System Generation" 

"Appendix G: Compatibility of VM/370 
with CP-67/CMS" 

"Appendix H: Creating a 3340 System 
Residence Volume from a Current 2314 



or 3330 System Residence Volume and 
the PLC Tape" 

"Part 1: Planning for System 
Generation" contains information that 
was formerly in "Section 1. 
Introduction," "Section 2. CMS 
Considerations," "Section 3. Operating 
Systems — General Information," and 
"Section 4. System Generation Planning." 
The following sections are new: 

• "Specifying a Virtual=Real Machine" 

• "Virtual Machine Assist Feature" 

• "VM/370 Using Channel switching" 



"Generating a VM/370 
Supports the 3704/3705" 



System that 



In addition, system generation 
considerations are now included in the 
"CMS Batch Facility" section, and the 
"Configurations" section is reformatted 
to improve its readability. 

"Part 2: Defining Your VM/370 System" 
describes the macros and programs that 
define VM/370. It contains information 
about the real I/O configuration file, 
CP system control file, system name 
table file, VM/370 Directory program, 
and the Forms Control Buffer. This 
information was previously in "Section 
4. System Generation Planning." 

"Part 3: Generating VM/370 (CP, CMS, 
and RSCS)" describes the step-by-step 
procedures for generating VM/370. It 
contains the information that previously 
was in "Section 5. Generating and 
Installing VM/370" and "Appendix G: 3330 
System Generation." 

"Part 4: Generating the 3704/3705 
Control Program" describes the 
step-by-step procedure for installing an 
Emulation Program, Network Control 
Program, or Partitioned Emulation 
Program. Previously, this information 
was in the VM/370; System Programmer's 
Guide. 

"Part 5: The Standalone Spool Remote 
Program" describes the procedure for 
installing the 2780 Spool Remote Program 
(DMKSRP) . Previously, this information 
was in the YM/370: System Programmer's 
Guide. 



"Part 6: Updating VM/370" tells you 
how to update VH/370 and describes the 
programs and EXEC procedures you need. 
Most of this information was in "Section 
6. Supporting and Updating an Installed 
System." The examples are clarified, 
the VHFASM command format is added, and 
the VMFBLD and aSMGEND EXEC procedures 
are now described. 

The following editorial changes were 
also made in the Appendixes: 

• "Appendix C: Command Privilege 
Classes," "Appendix D: CP Commands," 
and "Appendix E: CMS Commands" were 
deleted. This information is in the 
mZlZO* Command Language Guide for 
G6S6£3l Users. 

• "Appendix G: 3330 System Generation" 
is deleted. The information is 
included in "Part 3: Generating 
VM/370 (CP, CMS, and RSCS) ." 

• "Appendix H: CP Loadlist 
Reguirements" is deleted. The 
information now is included in the 
"Using VMFLCAD to Generate a New 
Nucleus" section of Part 6. 

The following Appendixes are new, 
although their contents are not new: 



The "Introduction to VM/370 System 
Generation" section of "Part 1: 
Planning for System Generation" is 
updated. 

The "CMS Planning Considerations" 
section of "Part 1: Planning for 
System Generation" is updated. 

The "Direct Access Storage 
Reguirements for CP" section of "Part 
1 : Planning for System Generation" is 
updated. 

The "Estimating DASD Storage 
Reguirements for CMS Minidisks" 
section of "Part 1: Planning for 
System Generation" is updated. 

The "Minidisks" section of "Part 1: 
Planning for System Generation" is 
updated. 

The "Configurations" section of "Part 
1: Planning for System Generation" is 
updated. 



"Part 2: Defining Your VM/370 System" 
is updated. The RDEVICE and SYSRES 
macros are updated and the "Creating 
Your VM/370 Directory" section is 
updated. 



• "Appendix E: Notational Conventions" 

• "Appendix F: VM/370 Service 
Programs." The service programs 
previously were described in "Section 
4. System Generation Planning." 



"Part 3: Generating VM/370 (CP, CMS, 
and RSCS) is updated to include a 
complete description of the system 
generation procedure for a 33U0 
starter system. 



"Appendix G: Compatibility of VM/370 
with CP-67/CMS." This information 
was in the VM/370: Command Lan^ua^e 
Guide for General Users. 



NEW DEVICE SUPPORT 



New: Program Feature 



"Appendix B: Configuration Aid" is 
updated. 

"Appendix F: VM/370 Service Programs" 
is updated. 

"Appendix H: Creating a 3340 System 
Residence Volume from a Current 2314 
or 3330 System Residence Volume and 
the PLC Tape" is added. 



The IBM 3340 Direct Access Storage 
Facility is now supported by VM/370. 
This support includes Rotational 
Position Sensing (RPS) and the 3348 Data 
Module, Models 35, 70 and 70F (supported 
as a Model 70) . The following changes 
to this publication reflect this 
support: 



VM/370 supports the IBM 3767 
Communications Terminal (at 300 bps) 
operating as an IBM 2741 Communication 
Terminal only. The "Configurations" 
section of "Part 1: Planning for System 
Generation" is updated to reflect this 
support. 



NEW SUBSYSTEM SUPPORTED AS VM/370 COMPONENT 



New: Component 
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files acr 
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stations, 
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changes reflect this 
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This virtual machine option may increase 
the throughput of the virtual machine's 
operating system because it allows the 
overlap of SIOs to virtual devices 
wxtiiOut encountering une cndnnex busy 
condition. The following changes to 
this publication reflect this support: 

• The "Performance Guidelines" section 
of "Part 1: Planning for System 
Generation" is updated. 

• The "Virtual Machine Options" section 
of "Part 1: Planning for System 
Generation" is updated to describe 

X1.A nMtr A*^J.4>^«. 



"Figure 1. Virtual Machine 
Facility/370 Library" includes two 
new publications. 

The "Introduction" section of "Part 
1: Planning for System Generation" is 
updated. 

The "Planning Considerations for 
Virtual Machine Operating Systems 
(other than CMS)" section of "Part 1: 
Planning for System Generation" is 
updated. 

The "Configurations" section of "Part 
1 : Planning for System Generation" is 
updated. 

"Part 3: Generating VM/370 (CP, CMS, 
and RSCS)" is updated to include a 
complete description of the system 
generation procedure for RSCS. 

"Part 6: Updating VM/370" is updated 
to include information about updating 
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Nucleus" section and in "Figure 27. 
System Support Plan." 

The VMFBLD EXEC procedure is updated 
to support RSCS. The changes are 
described in the "Using the VMFBLD 
EXEC Procedure to Build a New 
Nucleus" section of "Part 6: Updating 
VM/370." 

"Appendix C: Representative Directory 
Entries" has an entry for an RSCS 
virtual machine. 



ENHANCEMENT FOR THE VIRTUAL MACHINE 



New: Program Feature 

Programs using block multiplexer channel 
operations (for example, DOS/VS, VS1, 
and VS2) can now be executed in block 
multiplexer mode on the virtual machine. 



CMS ZAP SERVICE PROGRAM ENHANCED 



New: Program Feature 

The CMS ZAP service program is enhanced 
so that it can now modify or dump TXTLIB 
and MODULE files in addition to LOADLIB 
files. This support is described in the 
"Using the ZAP Program to Update CMS 
MODULE, LOADLIB, or TXTLIB Files" 
section of "Part 6: Updating VM/370." 



READING DOS FILES FROM DOS DISKS 



New: Programming Feature 

Using OS macros, CMS can now read DOS 

files that reside on DOS disks. No DOS 
macros are simulated. The "CMS Planning 

Consiuer a i.xons " s€Ci,xon oj. ''Pare i: 

Planning for System Generation" is 
updated. 



MISCELLANEOUS 



Changed: Program and Documentation 

The following miscellaneous changes were 
made: 

• The formula for calculating the 
maximum size virtual=real area 
allowed is changed. The formula is 
described in the "Specify a 
Virtual=Real Machine" section of 
"Part 1: Planning for System 
Generation. " 

• A new operand for the RDEVICE macro, 
FEATURE=2CHANSH or =4CHANSW is 
mentioned in the "VM/370 Using 
Channel Switching" and "Operating 



Systems Using Reserve/Release" 
sections of "Part 1: Planning for 
System Generation. " The features are 
described further in the "RDEYICE 
Macro" section of "Part 2: Defining 
Your VM/370 System." 

The "Real Storage Requirements for 
CP" section of "Part 1: Planning for 
System Generation" is updated. 

The DMKSNT modules that are supplied 
with the starter system are included 
in the "Preparing the System Name 
Table File (DHKSNT) " section of "Part 
2: Defining Your VM/370 System." 

The system generation procedure is 
rewritten. There is a separate 
procedure for each of the starter 
systems. Information about installing 
a CP nucleus with a virtual=real area 
is added. The system generation 
procedures are described in "Part 3: 
Generating VM/370 (CP, CMS, and 
RSCS) ." 



The GENERATE EXEC procedure is 
changed so that it does not 
automatically load the CP nucleus if 
it contains a virtual=real area. This 
procedure lets you check that there 
is sufficient virtual storage. Then, 
if you have enough virtual storage, 
you can load the CP nucleus from 
tape. These changes are described in 
the "Using the GENERATE EXEC 
Procedure to Generate a New CP or CMS 
Nucleus" section of "Part 6: Updating 
VM/370." 

The "RDEVICE Macro" and "RCTLUNIT 
Macro" sections of "Part 2: Defining 
Your VB/370 System" are updated to 
support a new device type, 3158; and 
a new control unit type, 3158. 
"Appendix B: Configuration Aid" is 
also updated. 



The CLASS= operand of the RDEVICE 
macro is clarified in "Part 2: 
Defining Your VM/370 System." 

An example of a real I/O 
configuration file is added to "Part 
2: Defining Your VM/370 System." 

The DMKSYS modules that are supplied 
with the starter systems are added to 
the "Preparing the CP System Control 
File (DMKSYS) " section of "Part 2: 
Defining Your VM/370 System." 

The VM/370 directories that are 
supplied with the starter systems are 
added to the "Creating Your VM/370 
Directory" section of "Part 2: 
Defining Your VM/370 System." 



The VMFBLD EXEC 
to: 

— Not load the CP nucleus if 
contains a virtual=real area. 



procedure is updated 
it 



— Update the CPEREP and Assembler 

modules and create auxiliary 

directories for them when it builds 
the CMS nucleus. 



These changes are described in the 
"Using the VMFBLD EXEC Procedure to 
Build a New Nucleus" section of "Part 
6: Updating VM/370." 

The CMSGEND EXEC procedure is changed 
so that it can generate a new 
Assembler module. This change is 
described in the "Using The CMSGEND 
EXEC Procedure to Generate a CMS 
Module" section of "Part 6: Updating 
VM/370." 

VM/370 supports the IBM 3704/3705 
Network Control Program Support 
Package for OS/VS (Order Ho. 
5744-BA2) in emulation mode only. 
"Part U: Generating the 3704/3705 
Control Program" is updated. 



Summary of Amendments 

for GC20-1801-3 

as updated by GN20-2639 

VM/370 Release 2 PLC U 



IBM 3704/3705 COMMUNICATIONS CONTROLLERS 
NETWORK CONTROL PROGRAM (NCP) AND 
PARTITIONED EHULATION PROGRAM (PEP) 

New: Program Feature 

VM/370 now supports all three of the 
3704/3705 control programs: 

• Emulation Program (EP) 

• Network Control Program (NCP) 

• Partitioned Emulation Program (PEP) 

The following changes reflect this 
support: 

• The Preface is updated. 

• A new section "Generating a VM/370 
System that Supports the 3704/3705," 
is included in "Section 4. System 
Generation Planning." 

• The description of the RDEVICE macro 



in "Section 4. System Generation 
Planning" is updated, 

"Appendix B. Configuration Aid" is 
updated. 

"Figure 32. CP Command Summary" in 
"Appendix D. CP Commands" is 



"Figure 33. CMS Command Summary" in 
"Appendix E. CMS Commands" is 
updated. 



MISCELLANEOUS 

Changed: Documentation Only 

The description of the MACS record in 
the "Control Files" section of "Section 
6. Supporting and Updating an Installed 
System" is updated. 



Sunaary of AmendBents 

for GC20-1801-2 

VM/370 Release 2 PLC 1 



HEW DEVICE SUPPORT 

Hew: Prograi Feature 

The following devices are now supported: 

• IBM 3066 System Console, Model 2 

• IBM 3272 Control Unit, Model 2 (local 
attachment) 

(local attachment) 

• IBM 3330 Disk Storage, Model 11 

• IBM 3333 Disk Storage and Control, 
Model 11 

• IBM 3420 Magnetic Tape Unit, Models 
H, 6, and 8 (6250 bpi density) 



changed to reflect enhancements to the 
CMS Editor associated with support of 
display devices. 



HEH PROGRAM PRODUCTS 



Hew: Programs 

xuc U.J jTXi/ J. wucwjvuut. v> wi&^xa.cd. , cue w^ 

BASIC Processor, and the Planning 
Systems Generator have been added to the 
list of Program Products executable 
under CMS. See "Appendix E. Language 
Processors and Emulators." 



READ-OHLY OS DATA SET ACCESS SUPPORT 

Hew: Program Feature 

CMS can now read, but not write or 
update, real OS sequential and 
partitioned data sets. 

IBM 3704/3705 COMMUHICATIOHS COHTROLLERS 

Hew: Program Feature 

This publication now includes 
information about the IBM 3704 and 3705 
Communications Controllers in network 
Control Program mode and Partitioned 
Emulation Program mode as well as in 
Emulation Program mode. 

VIRTUAL MACHIHE ASSIST FEATURE 

Hew; Program Feature 

The Virtual Machine Assist feature, 
available on the System/370 Models 135, 
145, and 158, reduces VM/370 overhead 
associated with running OS/VSl and 
DOS/VS operating systems in virtual 
machines. A new option, SVCOFF, has been 
added to the OPTIOH statement of the 
VM/370 Directory service program. See 
"Directory Creation Service Program 
(DMKDIR) " in Section 4. 

EHHAHCEMEHTS TO THE CMS EDITOR 
Hew; Program Feature 
"Section 2. CMS Considerations" has been 



MISCELLAHEOUS CHAHGES 

Changed; Program and Documentation 

The DMSGEH and DMKGEH EXEC procedures 
have been replaced by the VMFMAC EXEC 
procedure. See "The VMFMAC Procedure" 
under "Applying Updates" in Section 6. 

The GEHDECK EXEC procedure has been 
replaced by the GEHERATE EXEC procedure. 
See "The GEHERATE EXEC Procedure" in 
Section 6. 

The system generation procedure has 
changed. Read "Section 5. Generating 
and Installing VM/370." 

Information on generating a VM/370 
system that will include an IBM 
3704/3705 Communications Controller has 
been added. For this purpose, new 
operands are included in the RDEVICE 
macro, and a new macro, HAMEHCP, has 
been included. See "Preparing the Real 
I/O Configuration Deck" and "Configuring 
the HAMEHCP Macro" in Section 4. 

The MIHIDASD program has been replaced 
by the OS IBCDASDI service program. See 
"Virtual Disk Initialization Service 
Program (IBCDASDI)" in Section 4. 

Virtual console spooling now includes CP 
commands typed in by the user as well as 
CP messages and responses. 

Changed: Documentation only 

The section "DMKSRP Installation 
Procedure," on the IBM 2780 Data 
Transmission Terminal, has been removed 



from this publication and now appears in 
the YM/37p; System Pr ogranae r ^s Guid e. 

"Section 1. Introduction" now includes 
an introduction to the system generation 
process, for novice users. 

Information on generating a yirtual=real 
machine now appears under "VM/370 
Directory Entries" in Section U. 

A new discussion, "Estimating Storage 
Requirements for CHS Minidisks," has 
been added to Section 4. 

Information on configuring the HAHESTS 
macro, which formerly appeared only in 
the VM/370: Syste m P rogrammer's Guide, 
now also appears in Section 4. 

Information about the loader has been 
added to Section 6. See "The Loader 
(DMKLDOOE) ." 

The discussion "Applying an Update to 
the System — An Example" has been 
replaced by "Recommended Procedures for 
Local Modification." 

"Appendix A. Migration from CP-67/CMS to 
VM/370" has been removed. The same 
material is contained in the y M/370 ; 
Co mmand Language Cfuidg for Gene ra l Users 



in "Appendix G. Compatibility of VM/370 
with CP-67/CMS." 

"Appendix B. VM/370 Restrictions" has 
been removed. A complete list of 
restrictions appears in "Appendix E. 
VM/370 Restrictions" in the VM/370: 
Introducti on. 

The title "Appendix C. CP Command 
Privilege Classes" has been shortened to 
"Appendix C. Privilege Classes." 

The title "Appendix E. Supported 
Features and Devices" has been changed 
to "Appendix A. Language Processors and 
Emulators." 

The new "Appendix B. Configuration Aid" 
contains charts of control units and 
associated devices that will be helpful 
in preparing the Real I/O Configuration 
Deck. 

"Appendix D. CP Commands" and "Appendix 
E. CMS Commands" (formerly Appendix F) 
reflect new and changed commands. 

In addition, numerous technical 
corrections, editorial changes, and 
minor additions have been made 
throughout this publication. 
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Part 1: Planning for System Generation 



Part 1 contains planning information. It describes the 
various components, options, and features of VM/370 and tells 
you what you must do to install them. Part 1 contains the 
following sections: 

• Introduction 

• Performance Guidelines 

• CMS Planning Considerations 

• Planning Considerations for Virtual Machine 

Operating Systems (Other than CMS) 

• Generating a VM/370 System that Supports the 3704/3705 

• Saved Systems 

• Estimating VM/370 Storage Requirements 

• Minidisks 

• Configurations 
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Introduction 



The IBM Virtual Machine Facility/370 is System Control Program (SCP) 
that manages a real computing system so that all its resources — CPU, 
storage, and input/output devices — are available to many users at the 
same time. Each user has at his disposal the functional eguivalent of a 
real, dedicated computing system. Because this functional equivalent is 
simulated by VM/370 and does not really exist, it is called a "virtual" 
machine. 

I Vn/370 supports IBM System/370 Models 135, 145, 155 II, 158, 158MP 
! (uniprocessor mode) , 165 II, 168, and 168MP {in uniprocessor mode) . The 
real System/370 must have the Dynamic Address Translation feature, a 
hardware facility that translates virtual storage addresses to real 
storage addresses, and the System Timing facility. Also, it must 
operate in extended control mode, a mode in which all the features of a 
I System/370, including dynamic address translation, are operational. 

VM/370 has three components: 

• The control program (CP) , which controls the resources of the real 
computer to provide multiple virtual machines. 

• The Conversational Monitor System (CMS) , which provides a wide range 
of conversational and time-sharing facilities. Using CMS, you can 
create and manage files, and compile, test, and execute problem 
programs. 

I • The Remote Spooling Communications Subsystem (RSCS) , which transfers 
I spool files between VM/370 users and remote locations over 
I telecommunication lines. 

I For more information about VM/370, see the VM/370: Introduction. 



ZIIIOAL MACHINE OPERATING SYSTEMS 

While the control program of VM/370 manages the concurrent execution of 
the virtual machines, it is also necessary to have an operating system 
managing the work flow within each virtual machine. Because each 
virtual machine executes independently of other virtual machines, each 
one may use a different operating system, or different releases of the 
same operating system. 
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The operating systems that can run in virtual nachines are: 



Batch or 
Single J)ser_ Inter active jju It iele- Access 

DOS APL\DOS-360 

DOS/VS (with CP option) 

OS/PCP VM/370 

OS/MFT Time Sharing 

OS/MVT Option of OS 
0S/VS1 

0S/VS2 Conversational 

OS-ASP CMS 
RSCS 
PS44 



CP provides each of these with virtual device support and virtual 
storage. The operating systems themselves execute as though they were 
controlling real devices and real storage, but they must not violate any 
I of the restrictions listed in the VM/370: Introduction. 



INTROpOCTION TO VM/370 SYSTEM GENERATION 

The purpose of the system generation is to create a system that meets 
your installation's particular needs. 

The first step in the system generation procedure is to restore the 
starter system, a small working copy of a basic VM/370 system. Using 
the starter system, you tailor a VM/370 system to your own hardware 
configuration. You also describe your DASD volumes and define how they 
are to be used. 

There are three versions of the starter system you can order: 

• 2314 Starter System 

• 3330 Starter System 

• 3340 Starter System 

The 2314 starter system must be restored to a 2314 disk, but you can use 
it to build a 2314 or 3330 system residence volume. The 3330 starter 
system must be restored to a 3330 disk, but you can use it to build a 
2314 or 3330 system residence volume. The 3340 starter system must be 
restored to a 3340 disk, but you can use it to build a 2314, 3330, or 
3340 system residence volume. 

Before you begin the system generation procedure, you should: 

• Know which devices to include in your VM/370 system. 

• Create the real I/O configuration (DMKRIO) file describing your I/O 
configuration. 

• Decide how many virtual machines to define. 
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• Create the VM/370 directory control statement file describing the 

• Decide which volumes are to be owned and used by CP (for system 
residence, paging, spooling, and so on), the amount of real storage 
available to VM/370, and the user identification of the real system 
operator. 






• i;rea"ce tne i,e system conttox (umvoio) jLij.e ue&wrijjing (-r— owned 
volumes, the real storage size, and so on. 

• If you wish, you can create your own forms control buffer (module 
DMKFCB) and system name table (module DMKSHT) , These modules are, 
however, supplied with the starter system. 

Once you have defined your VB/370 system with these files, you can 
begin the system generation procedure. You should read the rest of Part 
1 to be sure you have all the information you need to generate your 
system. Part 2 has the information you need to code the files that 
define your system and Part 3 describes the system generation procedure 
step-by-step. Before you start the system generation procedure be sure 
you have the following manuals available: 

YMZJIO • Command Language Guide for General Users 

iM/370: Operator's Guide 

IMllQ.' System Messages 

1^/.11Q.' Terminal User's Guide 

During the system generation procedure, you apply the PLC tape 
supplied with the starter system. This updates your system to the 
current level. Then use the Installation Verification Procedure (IVP) 
to verify that the VM/370 system is functioning properly. 

If you wish to install the Remote Spooling Communications Subsystem 
fRSCS) . do so after running the IVP. After you qp-n^^ra+f* VM/^7n rcp. 
CMS, and optionally RSCS) you can generate the 3704/3705 Control Program 
or the 2780 Spool Remote Program. Information about generating these 
two programs is found in Parts 4 and 5, respectively, of this manual. 

You can generate a 3340 system residence volume without using the 
3340 starter system if you have: 

• A Release 2 2314 or 3330 system residence volume 

• The PLC tape that includes the 3340 support 

"Appendix H. Creating a 3340 System Residence Volume from a Current 
2314 or 3330 System Residence Volume and the PLC Tape" is a description 
of the procedure. 

Note: VM/370 strongly recommends that you use the 3340 starter system to 
create a 3340 system residence volume. The procedure described in 
Appendix H is complex and restricting; it reguires that you generate CP 
and CMS twice. 
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Performance Guidelines 



The performance characteristics of an operating system when it is run in 
a virtual machine environment are difficult to predict. This 
unpredictability is a result of several factors: 

• The System/370 model used 

• The total number of virtual machines executing 

• The type of work being done by each virtual machine 

• The speed, capacity, and number of the paging devices 

• The amount of real storage available 

• The degree of channel and control unit contention, as well as arm 
contention, affecting the paging device 

• The type and number of VM/370 performance options in use by one or 
more virtual machines 

Also, the virtual machine's channel mode, block multiplexer or selector, 
has an effect on the virtual machine's performance. 



I PERFORMANCE MEASUREMENT AND ANALYSIS 

The VM/370 control program has two commands that measure system 
performance and thus help you identify problem areas. The MONITOR 
command collects system measurement data offline for the system operator 
or system analyst, while the INDICATE command collects system 
measurement data online for the system analyst or general user. 

The MONITOR command gathers data relating to most aspects of system 
performance and writes the data on tape. Using the operands of the 
MONITOR command, you can designate the type of information you want 
collected. You must summarize or analyze the data written on tape to 
determine performance trends. You can write your own program to analyze 
the data collected on tape or use an Installed User Program (lUP) which 
is available through IBM. When the data collected on tape is 
summarized, it may indicate the conditions contributing to performance 
degradation. 

The INDICATE command displays, at the terminal, some key information 
about the system which shows the current performance indicators. 
INDICATE displays the system conditions existing at the time the command 
is issued. If, after using the INDICATE command, the system analyst 
wants more extensive data collection and reduction, he can use the 
MONITOR command. 

For information about using the MONITOR and INDICATE commands and for 
the format of the tape records created by the MONITOR command, see the 
mZlZOi System Programmer's Guide. 



16 VM/370: Planning & System Generation Guide 



GC20-1801-4, Page Modified by GN20-2658, March 31, 1975 

Performance Guidelines 

I fiSING THE PERFORMANCE OPTIONS 

The performance of a specific virtual machine can be improved by 
assigning it one or more performance options. These include: favored 
execution, priority, reserved page frames, locked pages, and 
virtual=real. 

The performance of a VM/370 system running virtual storage operating 
systems can be improved if you use the virtual machine assist feature. 
This feature is available as a hardware feature on the System/370 Models 
135, 145, and 158 and as an RPQ on the Model 168. In order to invoke 
the favored execution, priority, reserved page frames, and locked pages 
options you must have a virtual machine defined with the appropriate 
command privilege classes. Usually, the operator's virtual machine has 
the appropriate command classes. Additional planning is needed to 
support the virtual=real option and virtual machine assist feature. All 
of these performance options are described in detail in the VM/370: 
Sis tern Proc[rammer^s Guide. 



SPECIFYING A VIRTUAL^ REAL MACfilNl 

Although the virtual =real option eliminates paging, its main function is 
to bypass CCW translation. This is possible because I/O from a virtual 
machine occupying a virtual=real space contains a list of CCWs whose 
data addresses reflect the real storage addresses. 

The only exception is virtual page 0. Virtual page does not exist 
as real page 0; it is relocated beyond the highest page of the 
virtual=real area. In order for the virtual machine to perform I/O into 
virtual page 0, the CCW addresses must be translated. 

When CP loads an operating system into a virtual=real area, it turns 
on CCW translation. Once the operating system is loaded, the operator 
of the virtual machine should issue a CP command to turn CCW translation 
off. 
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When the virtual machine is operating with CCW translation off, it 
must not perform I/O into virtual page 0. Host operating systems can be 
generated so that they do not use this area for input/output. However, 
violdation of this restriction may cause damage to the other virtual 
machines. 

The size of the virtual=real area is specified during CP system 

generation. It must be large enough to contain the entire addressing 

space of the largest virtual machine that you execute in the 
virtual=real area. 

Only one virtual=real area can be defined. 

Only one virtual machine at a time can occupy the virtual =real area. 

Since the virtual=real option removes pages from the dynamic paging 
area, it affects the performance of other virtual machines. 

The virtual=real area is set up at VM/370 initial program load 
(IPL). It can be released by the primary system operator to be used as 
part of the dynamic paging area. once released, it cannot be reclaimed 
except by reloading VM/370. The virtual=real area must be released in 
total, that is, unused pages of the area cannot be selected for 
release. 

To use the virtual=real option effectively on a multiport 
teleprocessing system with no CCW translation (SET NOTRANS ON) , lines 
must be dedicated to that system via the ATTACH command or by VM/370 
directory assignment. Conversely, on a multiport teleprocessing 
virtual=real operation, virtual 2701/2702/2703 lines, (that is, lines 
assigned and used by CP's DEFINE and DIAL commands) operate with CCH 
translation. If you invoke the SET NOTRANS ON command it is nullified 
when a valid DIAL command is detected. 

Note that you cannot execute programs with dynamically or 
self-modifying channel programs in a virtual=real area if you also use 
the DIAL command. 

To generate CP so that it properly supports a virtual=real area you 
must do the following: 

• Specify the VIRT=REAL option in the VM/370 directory for all the 
virtual machines in your installation that you plan to run in the 
virtual=real area. 

• Reserve enough DASD space for the CP nucleus. A CP nucleus that 
supports a virtual=real area is larger than one that does not. 

• Make sure the virtual machine you are using to generate CP has 
sufficient virtual storage. 

• Specify the amount of storage you want reserved for a virtual=real 
area. 

"Part 2: Defining Your VM/370 System" describes the Directory 
program, including information about the VIRT=REAL operand of the OPTION 
control statement. 



RESERVING DASD SPACE FOR A CP NUCLEUS WITH A VIRTUAL=REAL AREA 

A CP nucleus with the virtual=real option requires more DASD space for 
system residence than a CP nucleus without the option. Use the 
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following fornulas to calculate the number of cylinders needed for 
system residence (disregard any remainders) : 

Humber of 2314/2319 cylinders = (96+ (VRSIZE/4) )/32 
Number of 3330/3333 cylinders = ( 1 1U+ (VRSIZE/U) ) /57 
Humber of 2305/3340 cylinders = (96+ (VRSIZE/4) )/24 

where VRSIZE is the size of the virtual=real storage area (in K bytes) . 
K represents 1024 bytes. This size must be at least 32K bytes. 

The number of cylinders you calculate here is the number you reserve 
on your system residence device. You need this information to code the 
SYSRES macro of your CP System Control file correctly. 

If you do not reserve enough DASD space for your CP nucleus, when it 
is written on the system residence volume your nucleus overlays other 
cylinders. 



VIRTUAL STORAGE REQUIREMENTS 

When you are generating VM/370 you have two constraints on the maximum 
virtual=real size you can specify: real storage and virtual storage. 
The 2314 or 3330 starter system virtual machine has a maximum storage 
size of 1M, which means no matter how large your real machine is the 
largest virtual=real area you can specify is 512K. If you want a 
virtual=real area larger than 512K you must log on a virtual machine 
that has sufficient virtual storage before you load the CP nucleus. 
This process is described in Step 17 of the 2314, 3330 and 3340 system 
generation procedures. 

Before you load the CP nucleus, you must be sure the virtual machine 
you are using has enough virtual storage to contain: 

• CMS (320K) 

• CP nucleus size (including the virtual=real area) 

If your virtual machine does not have enough virtual storage, redefine 
storage and IPL again before continuing. 



SPECIFYING THE AMOUNT OF VIRTUAL=REAL SPACE 

If you are generating your VM/370 system to include a virtual=real 
machine, in Step 16 of the system generation procedure you respond "yes" 
to the system message: 

VIRTUAL=REAL OPTION REQUIRED (YES, NO): 

You are then prompted to enter the size of the virtual=real machine 
size: 

STORAGE SIZE OF VIRT=REAL (MINIMUM IS 32K) : 
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Normally, you would not want to specify the largest virtual=real machine 
possible, since that would leave few page frames available for other 
virtual machines. 

At IPL time, the virtual=real area is locked in storage immediately 
following CP page 0. The system operator can issue the UNLOCK command 
with the VIRT=BEAL option to free the virtual=real area for additional 
dynamic paging space for other virtual machines. The area cannot be 
relocked; it remains unlocked until another system IPL. 

specify for some real machine sizes. 

Real Machine Size Maximum_VIRTf REAL_Size 

384K 136K 

512K 264K 

768K 516K 

1M 768K 

2M 1768K 

384K is the minimum real machine size on which you can have a 
virtual=real machine. 

Calculate the maximum amount of virtual=real storage available on 
your real CPU as follows: 

• Ose Formula 1 to calculate the amount of real storage available after 
CP reguired storage is allocated. 

• Use Formula 2 to calculate the maximum virtual=real size for any real 
machine size. 



I Calculating Available Real Storage (Formula X) 

Calculate the amount of real storage available (ARS) by subtracting the 
amount of storage reguired by CP from the real machine size. Formula 1 
is: 

r r Ti 

I |RM - 256KI I 

ARS = RM - II + T ♦ 12K + UK| 1| 

I I 64K I I 

L L J J 

where : 

RH is the real machine size. 

I is the amount of storage needed to IPL CP. Refer to the load 
map produced when the CP nucleus is generated. The amount of 
storage needed to IPL CP is all of storage up to, and 
including, the module DMKSAV. 

T is the amount of storage allocated for the CP internal trace 
table. CP allocates 4K of storage for each 256K of real 
storage for the CP internal trace table: 

r T 

I KM I 

4K I 1 

I256KI 

L J 
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If the calculation RM/256K results in a fraction, the result 
is rounded upward to the next higher integer. 

12K is the aiount of fixed free storage allocated for the first 
256K of real storage. 

r n 

|RM - 256KI 

4K| I 

I 6UK I 

L J 

is the amount of fixed free storage allocated for real storage 
beyond the first 256K. 

The result obtained from Formula 1 is the amount of available real 
storage (ARS) for a particular real machine size. This result is needed 
to calculate the maximum size of a virtual=real area in Formula 2. 



I Calculating the Maximum Size of the Virtual^ Real Area (Formula 2) 

Calculate the maximum size of the virtual=real area for a particular 
real machine size by recalculating the amount of real storage required 
by CP and subtracting that value from the real machine size. When you 
calculate the amount of real storage required by CP this time, you do 
not permanently allocate free storage for the portion of storage that is 
available for the virtual=real area (according to Formula 1) . The 
result of Formula 2 is the maximum size virtual=real area (VRS) you can 
specify for a particular real machine size. Formula 2 is: 

r r TT 

I |RM - 256K - ARS I | 

VRS = RM - II + T + 12K + 4K| 1| 

I I 64K II 

L L J J 

Use the same value for RM, I, and T as you used in Formula 1, ARS (the 
available real storage) is the result calculated from Formula 1. If the 
calculation 

RM - 256K - ARS 

64K 

results in a negative value, a virtual=real area is not supported (see 
Example 2) . If the same calculation results in a fraction, disregard 
the fraction (that is, round the result down to the next lower integer; 
see Example 3) . 

Example J 

Determine the maximum size of the virtual=real area for a real machine 
with 768K of storage that executes a VM/370 system that requires 228K to 
IPL. 

Formula X 

r r T r it 

I |768K| I768K - 256K| | 

ARS = 768K - I228K ♦ 4K| 1 + 12K + 4K| 1| 

I I256KI I 64K || 

L L J L JJ 
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ARS = 768K - [228K + 12K ♦ 12K + 32K] 
ARS = 768K - 28aK 
ARS = 48U K 
Formula 2 

r r TT 

I I768K - 256K - USaKI | 

VRS = 768K - !228K ♦ 12K ♦ 12K + UKj ;; 

i i 64K It 

L L JJ 

r r TT 

I I28KII 

VRS = 768K - I252K ♦ 4K| || 

I I6UKII 

L L JJ 

VRS = 768K - [252K + 4K[0]] 
VRS = 516K 
Note that the fraction (28/64) resulting from the 
RM - 256K - ARS 

calculation in Formula 2 is rounded down to the next lower integer, 
zero. 

Exaffl£le 2 

Determine the maximum size of the virtual=real area for a real machine 
with 320K of real storage. The VM/370 system reguires 228K to IPL. 

Formula 1. 

r r 1 r tt 

I |320K| I320K - 256K| | 

ARS = 320K - I228K + 4K| 1 + 12K + 4K| 1| 

I I256KI I 64K || 

L L J L JJ 

ARS = 320K - [228K + UK[2] + 12K + 4K ] 

ARS = 320K - [ 252K] 

ARS = 68K 

Note that the fraction 320/256 in the trace table calculation is rounded 
to the next higher integer, two. 

Formula 2 

r r TT 

I I320K - 256K - 68K| | 

VRS = 320K - I228K + 8K + 12K + 4K| 1| 

I I 64K I I 

L L J J 
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r r TT 

VRS = 320K - I248K ♦ '*K| — 1| 

i leaii 

L L J J 

Because the calculation 
EM - 256K - ARS 

results in a negative value (-U/64) , a virtual=real area is not allowed 
for this size real machine. In fact, 384K is the minimum real machine 
size that supports a virtual=real area. 

Example 3 

Determine the maximum size virtual=real area for a real machine with 
1792K of real storage. The VM/370 system requires 228K to IPL. 

Formula J 

I I1792KI I1792K - 256K| | 

ARS = 1792K - I228K + 4K| 1 + 12K + HK\ 1| 

I I 256KI I 64K || 

L L J L JJ 

ARS = 1792K - [228K + aK[7] + 12K ♦ 4K[2U]] 

ARS = 1792K - [ 228K + 28K + 12K * 96K] 

ARS = 1792K - [364K] 

ARS = m28K 

Formula 2 

r r TT 

I I 1792K - 256K - 1428K| | 

VRS = 1792K - I228K + 28K + 12K + HK\ 1| 

I I 6UK II 

L L JJ 

r r TT 

I I108II 

VRS = 1792K - I268K + 4K| || 

I I 641 I 

L L J J 

VRS = 1792K - [268K + 4K]] 

VRS = 1520K 

Note that the fraction (108/64) resulting from the 

RM - 256K - ARS 

64K 

calculation in Formula 2 is rounded down to the next lowest integer, 
one. 
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llMMh MCHINE ASSIST FEATURE 

The virtual machine assist feature is a combination of a CPU feature and 
VM/370 programming. It improves the performance of VM/370. Virtual 
storage operating systems which run in problem state under the control 
of VM/370 use many privileged instructions and SVCs that cause 
interrupts which VM/370 must handle. When the virtual machine assist 
feature is used, many of these interrupts are intercepted and handled by 
the CPU; and, conseguently, VM/370 performance is improved. 

The virtual machine assist feature is available as a hardware feature 
on the Systeffi/370 Models 135, 1U5, and 158 and as an RPQ on the Model 
168. 

Certain interrupts must be handled by VM/370. Consequently, the 
assist feature is not available under certain circumstances. VM/370 
turns off the assist feature in a virtual machine if it: 

• Has shared segments 

• Has an instruction address stop set 

• Traces SVC and program interrupts 

If you IPL a virtual machine operating system that has shared 
segments, the assist feature is turned off. If you later IPL an 
operating system that can run with the assist feature, CP turns the 
assist feature on again. 

Since an address stop is recognized by an SVC interrupt, VM/370 must 
handle SVC interrupts while address stops are set. Whenever you issue 
the ADSTOP command, VM/370 turns off the SVC handling portion of the 
assist feature for your virtual machine. The assist feature is turned on 
again after the instruction is encountered and the address stop 
removed. 

Whenever a virtual machine issues a TRACE command with the SVC, PRIV, 
BRANCH, INSTRUCT, or ALL operands, the virtual machine assist feature is 
turned off for that virtual machine. The assist feature is turned on 
agaxu Wuen tue tracxng xs compjLeteu. 

If the virtual machine assist feature is available on a CPU, the 
operator can turn the feature off, and on again, for the entire VM/370 
system. Also, if the feature is available to VM/370, each virtual 
machine operator can turn the feature off, and on again, for his own 
virtual machine. When you create your VM/370 directory, you can set off 
the SVC-handling portion of the virtual machine assist feature for 
various virtual machines by specifying SVCOFF on the OPTION control 
statement. 
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CMS Planning Considerations 



The Conversational Monitor system (CMS) is a component of VM/370 that 
provides a comprehensive set of conversational facilities to virtual 
machine users. CMS operates only in a virtual machine, and together 
with CP provides a time-sharing system suitable for program development, 
problem solving, and general time-sharing work. 

CMS is a required component of VM/370. You must generate CMS in order 
to support CP. 

This section contains the following information about CMS: 

Storage Requirements 

Device Support 

Libraries 

Command Language 

Program Language Facilities 

Limited Support of DOS and OS 

File Management 

Disk Management 

Tape Support 

Unit Record Support 

Editing 

Batch Facility 

Saving CMS 



CMS STORAGE RlSyiREMENTS 

CMS requires virtual storage and auxiliary storage. 

VIRTUAL STORAGE 

A minimum of 320K bytes for a CMS virtual machine, distributed as 
follows: 

• CMS nucleus — 128K 

• Loader tables — 8K 

• CMS user area — 184K (for application programs or CMS disk-resident 
commands) 

AUXILIARY STORAGE 

The CMS auxiliary storage requirements are: 

• System residence for CMS -- 110 cylinders on a 231U or 2319, 76 
cylinders on a 3330 or 3333, or 203 cylinders on a 3340. 
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Resident disk space for application programs (CMS commands, user 
pj^ogi^amc IBM Pro^ras Products^ ~~ the asicunt of s^iace needed is 
program dependent, and must be assigned by you. 

Hork space for application programs (CMS commands, user programs, IBM 
Program Products) — the amount of space is program dependent, and 
must be assigned by you. 



DEVICE SUPPORT 



CMS supports the virtual machine devices shown in Figure 2. 
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*The device addresses shown are those that are i^re assembled into the 

CMS resident device table. You can change these addresses using the 
CP DEFINE command. 

2The virtual address of the system console may be any valid 
multiplexer address. 

3The virtual device address (cuu) of a disk for user files can be any 
valid System/370 device address, and can be specified by the CMS user 
when he activates a disk. If the user does not activate a disk 
immediately after loading CMS, CMS automatically activates the user's 
primary disk at virtual address 191, the D-disk at 192, and the 
Y-disk (a read-only extension of the system disk) at 19E. 
I 

Figure 2. Devices Supported by a CMS Virtual Machine 



Under CP, unit record devices and the system console are simulated 
and mapped to different addresses and different devices. For instance, 
CMS expects a 3215, 3210, or 1052 type of operator's controle, but many 
I terminals are 2741s or 3270s. Regardless of the real device type, the 
virtual system console is a 3215. The control program of VM/370 (CP) 
handles all channel program modifications necessary for this simulation. 
CMS virtual disk addresses are mapped by CP to different real device 
addresses. 
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The CMS system disk, normally located at virtual address 190, is 
read-only and contains the CMS nucleus functions and disk-resident CMS 
command modules. The CMS nucleus is loaded into virtual storage when you 
issue the CP IPL command. CMS remains resident until another IPL command 
is entered or until you log off. The disk-resident modules are loaded 
into virtual storage only when their services are needed. 

The A-disk is a read/write disk and is the primary or first disk. 
Files that you wish to retain for later use are stored on one of your 
disks. Information stored on your disk remains there until you erase 
it. An exception is the temporary disk; files written on this disk are 
lost whe^ you log off. In addition to the system disk (S-disk) and 
primary disk (A-disk) , each CMS user can have up to eight additional 
disks. 

You can enter CMS commands and input files from the terminal and 
direct output files, program results, and error and prompting messages 
back to the terminal. 

The virtual card reader is used as the input medium for files, source 
decks, and data to be processed by your programs. The virtual card 
punch is used for your output files, language processor object decks, 
and various other types of data. The virtual printer is used for 
program results, storage dumps and language processor output. 

Under VM/370, the unit record equipment is normally spooled. CMS 
supports only spooled unit record devices. 

The following is an example of a VM/370 directory entry for a CMS 
virtual machine. 

USER 0SEB1 PASSWORD 
ACCOUHT HOMBER BIN? 
IPL CMS 

CONSOLE 009 3215 
SPOOL C 2540 READER A 
SPOOL D 2540 PUNCH A 
SPOOL E 1403 A 
LINK CMSSYS 190 190 R 
MDISK 191 2314 71 10 UDISKI W RPASS WPASS 

This entry describes the configuration when you log on as USER1. The 
Directory program control statements are described in Part 2. Briefly, 
this entry describes the USER1 virtual machine: it has a console at 009, 
a class A reader at OOC, a class A punch at OOD, a class A printer at 
OOE, a link to the CMS system disk (owned by userid CMSSYS) at 190, and 
a minidisk at 191. Once you are logged on you can change the 
configuration and also the spooling classes of the unit record devices. 
You can add devices to the VM/370 directory or dynamically add to the 
configuration as needed. 



CMS LIBRARIES 

CMS updates simulated partitioned data sets which contain: 

• CMS and OS macros to be used at assembly time (macro libraries) 

• Object routines to be referred to at execution- load time (text 
libraries) 
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The system macro libraries, located on the CMS system disk, are: 

Librar_y Contents 

CMSLIB MACLIB All of the CMS macros. 

OSMACRO MACLIB The selected OS macros from SYS1. MACLIB that are 

supported under CMS. 

0SMACR01 MACLIB The remaining distributed OS macros from 

SYS1. MACLIB. 

TSOMAC MACLIB The OS macros distributed in SYS1.TS0MAC. 

If you are a DOS user in a DOS virtual machine, you can punch the DOS 
macros on the virtual punch and create a new CMS macro library called 
DOSMACRO MACLIB. This library may be used to assemble DOS programs 
directly under CMS. However, DOS programs do not execute under CMS. 

The system text libraries, also located on the CMS system disk, are: 

Librarj[ Contents 

CMSLIB TXTLIB The CMS system text library. 

TSOLIB TXTLIB Selected TSO routines necessary to support 

certain features of the language Program 
Products. 

Execution-time libraries are available with the Program Product 
language processors and execute under CMS. 

You can generate your own libraries and add, delete, or list entries 
in them via the MACLIB and TXTLIB commands. You can also specify which 
libraries (system and user) to use for program compilation and execution 
via the GLOBAL command, which allows up to eight libraries to be 
specified. 



CMS COMMAND IjiMGOAGE 

The CMS command language lets you converse with CMS. iith this command 
language, you can use: 

• Language compilers 

• An Assembler 

• CMS file management system 

• Context editing and line editing 

• Execution control 

• Debugging capability 



Additionally, you can invoke the CP commands available to all virtual 
machines under VM/370 directly from CMS. Using these CP commands, you 
can send messages to the operator or to other users, dynamically change 
your virtual machine's configuration, and invoke spooling facilities. 
In CMS, the facilities of CP and CMS together appear as those of a 
single integrated system. 

To use CMS, you must first gain access to a virtual machine via the 
CP LOGON command, and IPL CMS. Then you can enter commands or data from 
the remote terminal (virtual operator's console). Each command, upon 
completion, returns control to you. For information about how to use 
CMS and for a description of all CMS commands, see the VM/370: Command 
Lan^ua^e Guide for General Users. 
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CMS PROGRAM LANGUAGE FACILITIES 

The languages available under CMS include: 

S/370 Assembler 

VS BASIC 

PL/I 

FORTRAN IV 

Full American National Standard COBOL 

The Assembler is distributed with VM/370. The language compilers 
that are program products must be ordered separately. For a complete 
list of language processors that can be executed under CMS, see 
"Appendix A. IBM Programs Executable Under CMS." 

CMS executes the compilers via interface modules. CMS commands are 
provided to invoke the compilers within the conversational environment 
of CMS. 

COBOL programs, using the following facilities, can be compiled under 
CMS, but must be transferred to a machine (virtual or real) running OS 
for execution. 

QSAM 8 BDAM spanned records 

ISAM 

RERUN statement 

label handling options 

OPEN REVERSED 

Sort feature 

Segmentation feature 

ASCII code feature 

Forced end of volume 

TCAM feature 

PL/I programs, using the following facilities, can be compiled under 
CMS, but must be transferred to a machine (virtual or real) runninig OS 
for execution. 

Multi-tasking 

Teleprocessing file support 

ISAM 

Backwards attribute 

Spanned records for buffered files 

Sort-merge 

Checkpoint- restart 

ASCII data sets 

Track overflow 



CMS TEXT PROCESSING FACILITY 

Text processing facilities that can create formatted output from one or 
more CMS files containing text and/or control words are available 
through the SCRIPT command. SCRIPT/370 is an IBM Installed User Program 
that must be ordered separately. 
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LIMITED SUPPORT OF OS AND DOS IN CMS 



Object prograns (TEXT files) produced under CMS and under OS in real or 
in virtual machines laay be executed under CMS if they do not utilize 
certain OS functions not simulated by CMS. Object programs using 
non-simulated OS macro functions must be transferred to an appropriate 
real or virtual OS machine for execution. 



Seguential and partitioned data sets residing on OS disks can be read 
by OS programs running under CMS. Also, certain CMS commands can be used 
to process data sets on OS disks. 

I CHS commands, and programs that use OS macros simulated by CMS, can 
I read sequential DOS files. No DOS macros are simulated; DOS files are 
I treated as if they were OS data sets and are read by OS macros. 

The application programmer who normally uses CMS to interactively 
create, modify, and test his programs may require facilities not 
supported in CMS (for example, an OS program using ISAM) . He can 
alternately execute CMS and another operating system in the same virtual 
machine. 

I A description of the actual processes for reading OS or DOS files and 
j of alternating operating systems is in the VM^IZO- Command LanSlilS® 
I Guide for General Users. 



CMS FILE MANAGEMENT 



CMS provides interfaces with virtual disks, tapes, and unit record 
equipment. Most CMS commands assume that files are stored on disk. This 
means that files stored on media other than disk must be transferred to 
disk before you can issue a CMS command that uses them, similarly, most 
CMS commands that create files do so on disk (such as listing files from 
a compilation) . In many cases you may want to transfer these files to 
cards or tape, or to print them. 



CMS DISK MANAGEMENT 



CMS can manage up to ten virtual disks (created on 2314, 2319, 3330, or 
3340 storage devices) for each user. One of these is the CMS system 
disk (S-disk) , a read-only minidisk, which normally has a device address 
of 190. Your files may be accessed from up to nine active CMS disks. 
Usually, one of these is a read/write disk called the A-disk with a 
device address of 191. 

Each CMS disk has a six-character label (or volid) associated with 
it. Record 3 (on cylinder 0, track 0), of a CMS disk includes a ten-byte 
label, consisting of the following: 

• Four characters: CMS= 

• Six characters: desired label 

(blank filled if less than 6 characters; truncated if more than 6 
characters) 

• The remaining bytes of the record are all binary zeros. 
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The CHS FORMAT command is used to initialize a disk area in the CMS 
format and to write a label onto a disk. All CMS disks must be 
formatted before being used for the first time. 

Disks do not need to be formatted for each session unless the disk is 
a temporary disk dynamically added to the virtual machine configuration 
via the CP DEFINE command. Dynamically defined disks must be formatted 
each time they are added to the virtual machine configuration. 

Each virtual disk has an automatically updated CMS file directory 
(called the Master File Directory) that keeps an inventory of all files 
on that disk. The file directory is updated after each CMS command that 
changes the status of files on that disk. A file directory has a name 
in the form of a single alphabetic letter A, B, C, D, E, F, G, S, Y, or 
Z, which corresponds to the mode letter of the ten possible user disks. 

The relationship between a file directory on a physical disk and the 
file directory name is established when you issue the ACCESS command. 

The data extent of a particular CMS file is limited to one virtual 
disk (up to 12,848,000 bytes). The file management system limits the 
number of files on any one virtual disk to 3400 (for 3330/3333/3340 
devices) or 3500 (for 2314/2319 devices) , and the number of records in a 
particular CMS file to 65,535. 



FILE MANAGEMENT 



CMS disks are formatted into 800-byte physical records or blocks. A 
3330 disk volume holds 14 physical blocks per track, a 3340 disk volume 
holds 8 physical blocks per track, and a 2314 or 2319 disk volume holds 
15 physical blocks for every two tracks. 

Logical records are imposed upon constant physical blocks as shown in 
Figure 3. Logical records can span physical blocks. 



First 800-Byte Data Block 

I 



REC1 



I REC2 



I REC3 



REC4 



REC5 



REC6 



Second 800-Byte Data Block 




Figure 3. File Format of Logical Records 
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Data records may be fixed-length or variable-length, but a mixture 
within a file is not permitted. Where necessary, items are begun in one 
block and continued in the next, for example, record 6 in Figure 3. 
Physical blocks are randomly assigned to a file as space is required, 

anfl T-al oa corl uKon nr>. Irsn/roT- in nc;o TKe rsVivc^ir'al hlrsr'lrc: ac:c;innofl + rs a 

file can be discontiguous, and are chained together by a series of 
pointers called a chain link, anchored in a File Status Table. Note that 
the entire 800 bytes of a data block are used. 

Space for required files (compiler work files, LISTING files, and 
object modules), as well as user created files, is automatically 
allocated by CMS. As a file grows, its space is expanded, and it is 
contracted if the space requirements are reduced. 






Disks can be accessed in two ways: read-only, where files on that disk 
can only be read; and read/write, where files can be read and written. 

To access a disk, you must: 

• Identify a disk as part of your virtual machine configuration. This 
disk is available if it is defined in your VM/370 directory entry, or 
it can be acquired dynamically by issuing the CP LINK or DEFINE 
command. 

• Identify the disk to CMS and assign it a file directory name. Use 
the ACCESS command after you load CMS. The CMS ACCESS command 
associates a particular disk with a given file directory name and, 
optionally, specifies which files on the disk are to be used and 
specifies the disk as read-only. 



Both CP and CMS can control read/write access to disks, as is 
illustrated in Figure 4. 



CP 



ACCE5S 



CMS ACCESS 



I 

I Read- 
I only 



I Read/ 
I write 



Read— only 
Read/Write 



I Read— only | Read-only 
I Read-only I Read/Write 



Figure 4. CP and CMS Disk Access 



The access allowed by CP is determined by your VM/370 directory entry 
or the form of the LINK command you issue for a particular disk. 

The disk access allowed by CMS is determined by the CMS ACCESS 
command. 
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FILE SHARING IN CHS 

Minidisks can be shared among CMS users via the VM/370 disk sharing 
facilities. Since CMS does not provide any control for multiple writes 
(ENQ, DEQ) , this form of CP sharing is not recommended. 

Each CMS file has an access mode associated with it at file creation. 
The filemode number of the file identifier determines the access mode. 
The following modes apply to CMS files: 

• Private 

• Read/write 

• Read/erase 

If you have read-only access to a disk, you cannot read a private 
file but can read all other files. However, if you have read/write 
access to a disk, you can read and write all the files, including those 
designated as private. 

Read/erase is a filemode normally used by the language processors for 
temporary work files. Once the file is read, it is automatically 
erased. 



CMS TAPE SUPPORT 

Each CMS machine can support up to four magnetic tape units at virtual 
addresses 181, 182, 183, and 184. They may be either 2401, 2402, 2403, 
2415, 2420, 3410/3411, or 3420 drives, or a mixture of tape drives. 

Each tape-handling command allows you to specify the mode of the tape 
(7-track or 9-track) , density, and tape recording technique: odd parity, 
converter on, translator off, or odd parity, converter off, translator 
on. 

If you do not specify the mode for a 7-track t.ape, CMS issues a mode 
set indicating 7-track, 800 bpi (bits per inch) , odd parity, converter 
on, and translate off. If the tape is 9-track, the mode is ignored and 
is assumed to be 1600 bpi for dual density drives and 800 bpi for single 
density drives. 

As an alternative to specifying mode in each tape command, you can 
issue a CMS TAPE command that sets the mode for the tape and stays in 
effect until reissued. You must do this if one of your programs is to 
use tapes in other than the default mode. 

With one exception, CMS commands permit only unlabeled tapes to be 
read or written. However, the CMS TAPPDS command can read standard OS 
tape labels. Your programs executing under CMS must use unlabeled tapes 
or provide code to create and read their own labels as data records. 

Multivolume tape files are not supported by CMS. 

Note: These restrictions only apply when you run CMS. DOS and OS 
systems running in virtual machines can continue to read and write tapes 
with standard labels, non-standard labels, and no labels on single and 
multireel tape files. 

The VM/370 operator must attached tapes to your CMS virtual machine 
before any tape operation can take place. 
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CMS UNIT RECORD SUPPORT 



CMS supports one virtual card reader at virtual address OOC, one virtual 
card punch at virtual address OOD, and one virtual printer at virtual 
address OOE. Under VM/370, these devices are spooled. CMS does not 
support real or dedicated unit record devices, nor does it support a 
virtual 2520 Card Punch. Figure 2 in this section lists the devices 
onppoj'+Q^ ao virtual devices b^ CMS^ 



CARD READER 

The READCARD command reads data records from the spooled card reader to 
a CMS disk. Input records of 151 or fewer characters are accepted. 
Column binary data is not acceptable. Your card decks must be read into 
the virtual reader before a READCARD command can be issued. You can do 
this in one of two ways: 

• Place a card deck, containing only one file, in a real card reader 
and have CP read it. The card images are placed on a spool file in 
the specified virtual machine's virtual card reader. If you are not 
logged on when data is spooled to your virtual card reader, the deck 
remains in your virtual card reader until you log on and issue the 
READCARD command. 

• Transfer records from your virtual card punch or printer to a virtual 
card reader (your own or that of another virtual machine) . 

For more information on reading files from the CMS card reader, see 
the VM/370: Command Languaae Guide for General Users. 



CARD PUNCH 

The CMS PUNCH command causes the specified file to be punched to the 
spooled card punch. Records up to 80 characters long are accepted. 
Shorter records are padded to 80 characters with blanks filled in to the 
right. The following are not supported: 

• Punch stacker select 

• Punch feed read 

• 3525 Multiline Card Print Feature 



PRINTER 

The PRINT command prints the specified disk file on the spooled 
printer. You can specify whether the first character of each record is 
to be interpreted as a carriage control character or as data. Both ASA 
and machine code carriage control characters are supported. The file 
may have either fixed or variable length records. 
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EDITING 

Using the CMS Editor, you can create new files online or modify or 
display portions of existing files. 

The CMS Editor operates on fixed and variable length records. The 

I Baximua record length accepted by the editor is 160 characters. You can 

specify file characteristics, such as record length, format, and tab 

locations. The system includes defaults for certain filetypes (such as 

ASSEMBLE and EXEC) . 

Files are edited in virtual storage. The maximum size file that can 
be edited is determined by the amount of virtual storage available to 
you, minus that used by the CMS nucleus. 

If the file does not fit into virtual storage, it must be divided 
into smaller files, and each file edited separately. Sufficient disk 
space must be available to accommodate both parts of the file. 
Alternately, you can temporarily increase the size of your virtual 
storage by issuing the CP DEFINE STORAGE command. 

For more information about the editing facilities of CMS, see the 
VMZ370: EDIT Guide. 



CMS BATCH FACILITY 

The Batch Facility is a VM/370 programming facility that executes under 
CMS. It allows you to execute jobs in batch mode. You can submit jobs 
from a virtual machine or from a real card reader. You do not have to be 
logged on to submit jobs to the batch virtual machine. Information 
about the CMS batch facility is in the VM^370: Command Language Guide 
tOiL General Users and operating information is in the VMZ370; Operator's 
Guide . 

If you want to use the batch facility you must define a CMS batch 
virtual machine when you create your VM/370 directory. You should 
include a read/write disk at virtual address 195 in the directory 
entry. Appendix C contains a batch virtual machine entry in its 
representative VM/370 directory. 

Also, you must have an entry in the VM/370 directory for each user 
that submits a job to CMS Batch. This entry can be the minimum: userid, 
password, and one device. For all users that submit jobs when they are 
not logged on, you code the password as NOLOG and do not need any 
devices defined in the VM/370 directory. Because users with a NOLOG 
password do not have devices defined for their virtual machines, CMS 
Batch uses the TO and FOB operands of the CP SPOOL command to transfer 
their files. 

The Batch Facility provides two entry points so you can add support 
to Batch that your installation may reguire. BATEXIT1 is provided so you 
can write your own routine to check non-CMS control statements. BATEXIT2 
is provided so you can process additional information on the /JOB card. 
These entry points are described in the VM/3 7O : System Programmerls 
Gu i d e . 

You can write EXEC procedures to control the operation of a Batch 
Facility virtual machine. See the VM/370: EXEC User^s Guide for examples 
of these EXEC procedures. 
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SAVING CMS 



CMS is designed so that it can be saved easily and so that the second 
segment of CMS can be shared by CMS users. The VM/370 starter system has 
entries in the system name table (DMKSNT) and CP system control file 
(DMKSYS) so that you can save CMS at the end of the system generation 
procedure for CMS. 

For more information about saved systems, see the "Saved Systems" 
section of this manual and see the YM/370: Sxstem Programmer's Guide. 
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Planning Considerations for Virtual Machine Operating Systems 
(Other Than CMS) 



This section contains information about the following: 

Virtual Machine Options 

Multiprogramning Systems 

Multiple Virtual Machines Using the Same Operating System 

Multiple Access Virtual Machines 

The RSCS Virtual Machine 

The ASP Virtual Machine 

VM/370 Using Channel Switching 

Operating Systems Using Reserve/Release 

CMS or any combination of operating systems such as OS/PCP, MFT, MVT, 
VS1, VS2, DOS, DOS/VS, and RSCS may be executed as operating systems in 
a virtual machine created and controlled by VM/370. Programs or systems 
to be run in a virtual machine, however, cannot include any hardware or 
software timing dependencies. For example, if I/O devices (or the 
programs that control them) require program responses within a defined 
time for correct data transmission, they may not work correctly. 
Execution of programs under VM/370 that require dynamic modification of 
channel programs is allowed only in certain cases: they can be executed 
in a virtual machine with the VM/370 performance option called 
virtual=real, an OS ISAM program can execute in a virtual machine if the 
ISAM option is specified in the VM/370 directory entry for that virtual 
machine, or an OS/VS TCAM program can execute in a virtual machine that 
has OS/VS TCAM Level 5, generated or invoked with the VM/370 option. 
Each operating system under VM/370 control requires that the virtual 
machine have an I/O configuration compatible with the one for which the 
operating system was originally generated. 

The environment of multiple virtual machines permits several of these 
systems to be executing concurrently. Production work may be run in one 
or more virtual machines while other virtual machines are executing: 

• A terminal-oriented conversational system. 

• A remote spooling subsystem, which transmits bulk data to and from 
remote locations. 

• A back-release system running application programs not upgraded to 
the current level of the production system. 

• A current-release system with new Program Temporary Fixes (PTFs) 
applied. 

• A new release or option being generated and tested. 

The interactive execution of conventional operating systems in a 
virtual machine environment provides several convenient operating 
facilities. Some of these are: 



Sistem Programming 

• Testing of new or modified Supervisor Call (SVC) routines on a 
virtual machine. 
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• Applying and testing PTFs on a virtual machine. 

• Generating and testing new releases of an operating sytem in a 
virtual machine. 

• Hands-on console debugging as though on a dedicated real machine, via 
a terminal device. 



AEEli£§ti25 Progr amm ing 

• Debugging while under operating system control, from a terminal. 

• Designing of application programs without real storage constraints. 

• Defining minidisks and other virtual devices to design and test a 
slightly different or larger machine configuration before the actual 
hardware is installed. 



OEgrations 

• Training of operators in their own virtual machine. 

• Defining a virtual machine and its devices as backup to some other 
real machine. 

• Permitting divergent installation requirements to be run concurrently 
on a single real machine. 



VIRTUAL MACHIJE OPTIONS 

VH/370 provides several optional services to virtual machines, 
including: 

• The REALTIMEH option, which updates a virtual machine interval timer 
when that virtual machine is in a self-imposed wait state. This 
option is required for virtual machines running systems that wait for 
a timer interrupt to continue processing. 

• The ISAM option, which allows the virtual machine to execute the 
self-modifying CCW command sequences generated by the OS ISAM modules 
in OS PCP, MFT, or MVT. This option is not required for the proper 
functioning of ISAM in DOS or OS/VS. However, if ISAM is run in the 
virtual=real area of an OS/VS virtual machine, the ISAM option is 
required. This option does not permit other types of self-modifying 
CCW sequences to function. 

• The ECMODE option, which allows the virtual machine to use the 
complete set of virtual System/370 control registers and the dynamic 
address translation feature of the System/370. Programming simulation 
and hardware features are combined to allow use of all the available 
features in the hardware. 

• The BMX (virtual block multiplexer) option, which allows an operating 
system that is running in a virtual machine to overlap multiple SIO 
(Start I/O) requests on a specified channel path (this is done in the 
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real block Bultiplexer environment) . The selector channel mode is the 
normal (and default) channel node for virtual machines. Hhen the BM^ 
option is invoked, it applies to all channels in the virtual machine 
except channel or channels that have a channel-to-channel adapter 
(CTCA) . The CP DEFINE command can redefine the channel mode for a 
virtual machine. 

The REALTIMEH, ISAM, and ECMODE options increase the amount of CP 
overhead incurred by the virtual machines using them, and should not be 
given to a virtual machine unless they are required. These options are 
specified in the OPTION statement in the VM/370 directory. If a 
particular option requires an option only occasionally, you may choose 
to define two virtual machines: one with the option specified, and one 
without; in this way, the additional overhead is incurred only when 
necessary. 

The REALTIMER can be set off by a user with the CP SET TIMER command. 
Timers are described in the 7M^370; System Pro^rammerls Guide. 

For more information about these and the other options (ACCT, 
VIRT=REAL, and SVCOFF) that can be specified in the OPTION statement, 
see the "Creating Your VM/370 Directory" section of Part 2. 



OS ISAM CHANNEL PROGRAMS 

Certain OS/PCP, MFT, and MVT ISAM channel programs use a self-modifying 
operation that is not allowed under normal VM/370 processing. With the 
ISAM option selected, CP can scan the specific OS/PCP, MFT, and MVT ISAM 
channel program to handle the self-modifying sequence properly. 

Only those users with the ISAM option in their VM/370 directory entry 
have their CCW strings checked for self-modifying operation; thus not 
all users incur the additional CP overhead. This option is not needed 
for DOS or OS/VS ISAM (except when OS/VS ISAM is executed in a 
virtual=real area of an OS/VS virtual machine) . 



HUIjTIPROGRAMMING SYSTEMS UNDER VM/370 

When a multiprogramming system such as OS or DOS is run on a virtual 
machine, its resource algorithms interact with those of VM/370; 
especially when the virtual operating system has a page wait or I/O 
wait. There are two methods in which multiprogramming systems interact 
with VM/370: one method is without the benefit of a special 
communication path and the second method is with the special path. The 
communication path, called the VM/VS Handshaking feature, is only 
available for 0S/VS1 virtual machines. 



I MULTIPROGRAMMING SYSTEMS WITHOUT THE VM/VS HANDSHAKING FEATURE 

P^a® W^iis in a Virtual Machine 

If, during its execution, an OS- or DOS-created task or program must 
wait for a CP-provided service such as a virtual storage page, the 
virtual machine is marked non-dispatchable even though other partitions 
or tasks in that virtual machine may be ready and available to run. 
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Those other tasks in the virtual machine cannot be dispatched by the 
oDeratinn svsteffl until the CP '^a'le wait is satisfied. The net effect is 
that the highest priority program of the virtual machine gets almost all 
the available CPU time', and the other programs experience significant 
degradation. 

When multiprogramming systems must be run in a virtual machine, 
consider using the virtual=real option, reserved page frames, or locked 
pages. When the virtual^real option is used, paging is eliminated. The 
reserved page frames option tends to keep the most active pages in 
storage and the locked pages option locks the specified pages in 
storage. 



IZO Kiii§ is § Xi£tS§l ^^chine 

On a real machine, when a task is waiting for an I/O operation to 
complete, the lower priority tasks are given use of the CPU. Under 
VM/370, the I/O operations of a particular virtual machine are 
overlapped with the CPU execution of that and other virtual machines. 
Consequently, lower priority tasks created by OS and DOS are given the 
CPU resource less frequently when executing in a virtual machine than 
when executing in a real machine. 

The system operator can issue the CP command SET FAVORED for a 
specific virtual machine to ensure that its lower priority DOS or OS 
tasks have a chance to execute. The favored execution option reduces 
the effect of a variable system load on the favored virtual machine. 

In addition, the assured percentage can be specified to guarantee 
that a certain amount of CPU time is made available to the virtual 
machine, provided that it is able to use the time. 

The system operator can also set the priority of a virtual machine by 
issuing the CP command SET PRIORITY. A low value gives the virtual 
machine a higher priority, and ensures that it is dispatched for 
execution more frequently than other virtual machines. 



Spoolinq Considerations 

Most multiprogramming operating systems provide their own spooling 
facilities. Since VM/370 also provides these facilities, double spooling 
can occur. If you have a significant amount of printing or punching to 
do, you may think one of the spooling facilities should be eliminated. 
This is not necessarily true. In fact, if the multiprogramming operating 
system's spooling facility blocks its output (such as 0S/VS1 does), the 
most efficient spooling arrangement is usually to let both VM/370 and 
0S/VS1 spool. When a virtual machine operating system blocks its 
output, VM/370 has fewer SIOs to process. 

See the YM/370: Command Lanjuacfe Guide for General Users for more 
information about punching and printing in a virtual machine. 

If a virtual machine without the handshaking feature shares real unit 
record devices with other virtual machines, the CP spool files are not 
closed until the virtual machine operator closes them. This means the 
CP spool files are not sent to the real printer or punch until the 
virtual machine operator intervenes. 
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I THE VM/VS HANDSHAKING FEATURE 

The VM/VS Handshaking Feature is a communication path between VM/370 and 

0S/VS1 that makes each system control program aware of certain 

capabilities and requirements of the other. The VM/VS Handshaking 
feature consists of: 

• Processing VSl pseudo page faults 

• Closing VM/370 spool files when the VSl job output from its Direct 
System Output (DSO) , terminator, and output writers is complete 

• Providing an optional nonpaging mode for VSl when it executes under 
the control of VM/370 

• Providing miscellaneous enhancements for a VSl virtual machine 
executing under the control of VM/370 

A page fault is a program interrupt that occurs when a page that is 
marked "not in storage" is referred to by an instruction in an active 
page. The virtual machine requesting the page is placed in the wait 
state while the requested page is brought into real storage. However, 
with the handshaking feature, a multiprogramming VSl virtual machine 
executing under the control of VM/370 may dispatch one task while 
waiting for VM/370 to honor a page request for another task. When the 
pseudo page fault portion of VM/VS Handshaking is active, VM/370 sends a 
pseudo page fault (program interrupt X'14») to VSl. When VSl recognizes 
a pseudo page fault, it places only the task waiting for the page in 
page wait and can dispatch any of its other tasks. 

When the handshaking feature is active, VSl closes the CP spool files 
by invoking the CP CLOSE command when the VSl job output is complete. 
Once these spool files are closed, they can be processed by VM/370 
without operator intervention. 

VSl can execute in nonpaging mode. Nonpaging mode exists when (1) 
the handshaking feature is active, and (2) the VSl virtual storage size 
equals the virtual storage size of the VM/370 virtual machine. When VSl 
executes in nonpaging mode, fewer privileged instructions are executed 
and duplicate paging is eliminated. Note that a VSl virtual machine may 
have a larger working set when it is in nonpaging mode than when it is 
not in nonpaging mode. 

Also, there are some other enhancements for VSl executing under the 
control of VM/370. With the handshaking feature, VSl avoids some of the 
instructions and procedures that would be inefficient in the VM/370 
environment. 

When the VM/VS Handshaking feature is active, the operation of VSl 
with VM/370 more closely resembles the standalone operation of VSl, 
because: 

• One VSl task can be dispatched while another is waiting for a page to 
be brought into real storage. 

• There is less need for the virtual machine operator to intervene 
because output files are automatically closed and processed. 

Also, a VSl operating system with the VM/VS Handshaking feature can 
execute by itself on a real machine or under the control of VM/370. 
Although handshaking is a system generation feature for VSl, it is 
active only when VSl executes under the control of VM/370; it is 
disabled when that same VSl operating system is run on a real machine. 
The VM/VS Handshaking feature is not active unless: 
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I • VSI is generated with the VM/370 option. 

I • VSI is run under the control of a version of VM/370 that supports the 
I feature. The VH/VS Handshaking feature is available with Release 2 
I PLC 13 of VM/370. 

I Even when the handshaking feature is active for an 0S/VS1 virtual 

I nachine, the pseudo page fault portion of the handshaking feature is not 

I available until it is set on with the CP SET PAGEX ON coamand. The CP 

I SET coiaand can set pseudo page fault handling on and off. 



HSIiTIPLE VIRTUAL MACHINES USING THE SAME OPERATING SYSTEM 

In general, an operating systea which is to run in a virtual machine 
should have as few options generated as possible. This is also true 
when several virtual machines share a system residence volume. Very 
often, options that improve performance on a real machine have no effect 
(or possibly an adverse effect) in a virtual machine. For example, seek 
separation, which improves performance on the real machine, is redundant 
in a virtual machine: CP itself issues a standalone seek for all disk 
I/O. 
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Sharing the system residence volume avoids the necessity of having to 
keep multiple copies of the operating system online. The shared system 
residence volume should be read-only. 

The CMS system residence volume is already read-only so nothing 
special need be done to share it among virtual machines. The OS system 
can be shared among users is all data sets with write access are removed 
from the system residence volume. The DOS system residence can be 
shared among virtual machines if each virtual machine has a unique 
standard label cylinder and its own read/write private core image 
library where it can catalog programs. Some change to DOS is necessary 
to sup,port shared system residences. Refer to the YH^370: System 
E£23I5mmer^s Guide for more details. 



SfiiillllsIrlCC^SS VIRTUii MACHINES 



Multiple-access programs are those which execute in a virtual machine 
and directly control terminals. These terminals need not be of the type 
supported by CP as virtual operator consoles, but may be of any type 
supported by the virtual machine. The lines used are either dedicated 
to the virtual machine via the directory entry or assigned to the 
virtual machine dynamically. 

A subset of the lines of a real transmission control unit (TCU) can 
be defined as a virtual TCO for a virtual machine, as shown in Figures 5 
and 6. 

Figure 5 shows two multiple-access systems (controlled by virtual 
machines VM1 and VM2) . Each controls real 3277s by using part of the 
resources of the real 3272, but it appears to both virtual machines as 
if they each have sole control of the real 3272. (The virtual system 
consoles of VM1 and VM2 are not shown.) 



VM1 



VM2 



Control Program of VM/370 



Virtual 
3272 



I Virtual 
I 3272 



Real 



3272 



I 



I Real I I Real | | Real | | Real | 
I 3277 I I 3277 | | 3277 | | 3277 | 

Figure 5. Virtual Devices: 3270 Terminals 
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Figure 6. Virtual Devices: Teleprocessing Units 



In Figure 6, two lines on the real 3705 are defined as virtual 
transmission control units for two virtual machines named VM1 and VM2. 
The remaining lines may support virtual operator consoles. 
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The virtual machine operating system may be one like APL DOS-360 
(with the CP option invoked) that supports a number of remote terminals, 
as shown in Figure 7. 

When the terminals supported by the virtual machine's operating 
system are of the same type as those supported by VM/370 as virtual 
system consoles, a real line can be assigned to a virtual TCD. 

To do this, virtual lines are defined in the virtual machine's VM/370 
directory entry via the SPECIAL record, or are added to the logged-on 
virtual machine via the CP DEFINE command. 
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Figure 8 illustrates a VM/370 directory entry for a multiple-access 
virtual machine to run APLxDOS— 360 (with the CP option) . 



USER 



APLSYS 051243 



256K 



CONSOLE OIF 
SPOOL OOC 
SPOOL OOD 
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DEDICATE 190 
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SYSWRK 
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IBM 
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IBM 
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IBM 
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Figure 8. VM/370 Directory Entry for an APL\DOS-360 Virtual Machine 



You can use the CP DIAL command to connect a terminal supported by 
both CP and a multiple-access system. Such terminals can be on either 
nonswitched or switched lines. To connect to the virtual machine in 
Figure 8, you would enter the command as follows: 

DIAL APLSYS 

The CP system matches the terminal type with an equivalent virtual 
line that is available and enabled (in this example, 080, 081, 082, or 
083) . Once a connection is made, the terminal is controlled by the 
virtual machine to which it is logically connected (in this example, the 
APL\DOS-360 virtual machine) , and neither you nor the terminal can issue 
any CP or CMS commands. It remains connected until you log off APL using 
standard APL logoff procedures, or until the APL virtual machine is 
logged off. You are then free to log on CP or to DIAL another 
multiple— access system. 

Dial— up terminals supported by the multiple-access system may be of a 
different type than those supported by VM/370 as virtual system 
consoles. Such terminals must be on switched lines, and the CP DIAL 
command cannot be used. You must dial the multiple-access system's 
telephone numbers directly. 
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In addition, a communications system can te tested using multiple 
virtual machines in place of multiple real machines, as shown in Figure 
9. The virtual 2701 units could each be defined as a one— line 2701; on 
the real machine there exists a single two-line 270 1. 



System/370 




VM2 
I 1 



VM/370 



Virtual 2701 



I Virtual 2701 



Real 2701 



I Data I < 

I Set I Communications Line 
I I 



-> I Data I 
I Set I 
I I 



Figure 9. A Communications System Test 

The communications system test in Figure 9 is based on the assumption 
that the real transmission control unit is equipped with the appropriate 
data sets and line capability. 

Figure 10 illustrates a virtual transmission control unit running 
remote 3270-type units. 

When the terminals supported by the multiple— access system are not of 
the type supported by VM/370 as virtual operator consoles, the real line 
appearances must be: 

• Defined in the VM/370 directory entry for the virtual machine via the 
DEDICATE record, as 

DEDICATE cuu 

where cuu is the real address of the appropriate line appearance on 
the real transmission control unit 

— or — 

• Attached to the virtual machine by an operator with privilege class B 
as 

ATTACH cuu TO VM 1 AS vcuu 
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where cuu is the real address of the appropriate line appearance on 
the real transmission control unit, and vcuu is the address of the 
line appearance as generated in the virtual machine operating 
system. 
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Figure 10. A Virtual TCO Running 3270-Type Units 



PERFORMANCE CONSIDERATIONS 



When virtual machine activity is initiated on an infrequent or irregular 
basis, such as from a remote terminal in a teleprocessing inquiry 
system, some or all of its virtual storage may be paged out before the 
time the virtual machine begins processing. The paging activity 
required so that the virtual machine can respond to the teleprocessing 
request may cause an increase in the time required to respond to the 
request. 

Use the locked pages or reserved page frames options to improve 
performance. 

If the program must be run in the dynamic paging area, then locking 
specific pages of the virtual machine into real storage may ease the 
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problem. However, it is not always easy or possible to identify which 
specific pages are always required. 

A more flexible approach than locked pages is the reserved page 
frames option. When a temporarily inactive virtual machine having this 
option is reactivated, these page frames are immediately available. If 
the program code or data required to satisfy the request was in real 
storage at the time the virtual machine became inactive, no paging 
activity is required for the virtual machine to respond. 



I THE RSCS VIRTUAL MACHINE 

The Remote Spooling Communications Subsystem (RSCS) , operating in a 
virtual machine, handles the transmission of files between VM/370 users 
and remote terminals and stations. Figure 11 illustrates a typical RSCS 
configuration. 

Three lines of the real 3705, operating in 2703 emulation mode, are 
shown dedicated to the RSCS virtual machine. The communication lines are 
shown attached to a 3780 Data Communication Terminal, a System/3, and an 
OS/HASP processor running in a remote System/360 or System/370. 

The RSCS machine uses the spooling facilities of VM/370 as the 
interface between virtual users and itself. Any user who wishes to have 
an output file transmitted to a remote location must associate tag 
information (such as destination and priority) with his file via the TAG 
command and spool the file to the RSCS machine's virtual reader. RSCS 
analyzes the tag data, enables the appropriate line, and transmits the 
data using the line protocol required by the receiving station. 

Remote locations can submit card files to the RSCS machine and 
address them to either a VM/370 user or to RSCS itself for transmission 
to another remote station. RSCS produces a VM/370 spool file by writing 
that data to virtual unit record devices and, if the file is destined 
for a VM/370 user, sends it to the user's virtual reader via the CP 
SPOOL command. If the file is addressed to RSCS, it is queued on RSCS's 
virtual reader and then handled in the same manner as a file spooled to 
RSCS by a VM/370 user. In this case, it is the responsibility of the 
remote station that originated the data to supply the tag information. 

RSCS can also function as a remote workstation of a HASP/ASP type 
batch processor. VM/370 users and remote stations can submit jobs to 
RSCS for transmission to the HASP system. After processing, HASP can 
return printed and/or punched output to RSCS for spooling to the real 
system printer or punch. For more information about RSCS, see the 
Z11Z370: ReS2i§ Spoolincf Communications Subsystem (RSCS) User^s Guide. 



I RSCS PLANNING CONSIDERATIONS 

I All the files you need to generate RSCS are on the PLC (Program Level 

I Change) tape. 

I Before you perform the RSCS generation procedure, be sure you have a 

I virtual machine defined for RSCS. The virtual machine you intend to run 

I RSCS should have: 
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I Figure 11. A Remote Spooling Communications Subsystem 



• 512K of virtual storage 

• A console 

• A 5-cylinder minidisk for the RSCS system residence volume. The RSCS 
system disk must have a write password. 

You can define more than one RSCS virtual machine. Also, you can 
have more than one RSCS virtual machine running at the same time. 
However, when multiple RSCS virtual machines are running at the same 
time, each must have a unigue user identification (userid) and local 
location identification (ID=linkid) . 

When you code the GENLINK macros during the RSCS generation 
procedure, you must code the local location identification on the first 
GENLINK macro. 

Information about generating and installing RSCS is in "Part 3: 
Generating VM/370 (CP, CMS, and RSCS)." 



THE ASP VIRTUAL MACHINE 



If you use the OS Attached Support Processor (ASP) you may find virtual 
machines useful in two ways. 
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First, a virtual ASP system can be run by two virtual machines (VMl 
and VM2) together with a virtual channel-to-channel adapter (CTCA) . 
This is illustrated in Figure 12. 
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I 
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Virtual CTCA 
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Figure 12. A Virtual Machine ASP System 



The virtual ASP system (VMl and VM2) shown in Figure 12 may be used 
to install and test a new ASP release, or for ASP system testing in a 
virtual environment concurrent with normal production. This eliminates 
the need to dedicate the real ASP computer for new system testing. 

The VM/370 directory entry for each of the virtual ASP processors 
must contain a record defining a virtual channel-to-channel adapter in 
the form: 

SPECIAL 280 CTCA 

where 280 is the address of the channel-to-channel adapter as generated 
in the OS system. 

When both virtual ASP machines are logged on VM/370, the CP COUPLE 
command must be issued by one of the virtual machine operators: 

couple 280 to vm2 380 

where 280 is the address of VMI's virtual channel-to-channel adapter, 
VM2 is the userid of the second virtual machine, and 380 is the address 
of VM2's virtual channel-to-channel adapter. After the channels are 
coupled, the operator of each virtual machine can then IPL his OS system 
and start running ASP. 

Second, an additional virtual machine (VM3) , with a real 
channel— to— channel adapter to a real System/360 or System/370, can be 
running as either the main or support processor in a production ASP 
system. This is illustrated in Figure 13. 
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Figure 13. A Virtual Machine in an ASP Configuration 



The real channel-to-channel adapter must be defined in the VM/370 
system generation procedure via the RDEVICE macro with a device type of 
CTCA {DEVTYPE=CTCA) . The virtual machine (VM3) must have this device 
assigned to it before the IPL. This can be done via the DEDICATE 
statement in the virtual machine's VM/370 directory entry as follows: 

DEDICATE 280 380 

where 280 is the address of the channel-to-channel adapter as generated 
in the OS system, and 380 is the address of the real channel-to-channel 
adapter as specified in the VM/370 system generation procedure. 

If there is no DEDICATE statement for the channel-to-channel adapter 
in the virtual machine's directory entry, a resource operator with 
privilege class B must attach the real channel-to-channel adapter to the 
virtual machine. 

Note: See the description of the COUPLE, DEFINE, and DETACH commands in 
the VM/370: Command Lanauaae Guide for General Users for further 
information on the virtual channel-to-channel adapter. 



I 115/370 USING CHANNEL SWITCHING 



VM/370 does not itself include any channel switching facilities. 
However, channel switching can be used between VM/370 and another 
operating system if the other operating system supports channel 
switching. The two- or four-channel switch can be used between: 

• Two CPUs, one running VM/370 and the other running an operating 
system that supports channel switching. 

• VM/370 and an operating system running in a virtual machine under the 
control of VM/370 on one CPU, if the virtual machine operating system 
supports channel switching. 
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I CHANNEL SWITCHING BETWEEN TWO CPUS 



I You can use the two- or four-channel switch for devices attached to two 
I CPUs. For example, one CPU could be running VM/370 and the other could 
I be running OS. The configuration is: 



CPU1 

r I 

I OS h 

I I 

1 I 



CPU2 

I 1 

I I 
I VM/370 h 



Channel | 
Switch y- 



290-297 
390-397 



VM/370 requires the following 
this configuration: 



BDEVICE and RCTLUNIT macros to support 



RDEVICE ADDRESS= (290,8) , DEVTYPE=3330, FEATURE = 2CHANSW 

RDEVICE ADDRESS=(390,8) ,DEVTYPE=3330 ,FEATURE=2CHANSW 

RCTLUNIT ADDRESS=290,CUTYPE=3830 

RCTLUNIT ADDRESS=390,CUTYPE=3830 

These macros make it possible for you to run VM/370 on CPU1 or CPU2. If 
you are always going to run VM/370 on CPU2, you can eliminate one path 
(eliminate one RDEVICE and RCTLUINT set of macros) . 



If any I/O devices 
attached to a control 
controlling the other 
offline. For example, 
are mounted and two 
system residence and 
running on CPU1 must 
protects volumes that 



controlled by VM/370 for its own exclusive use are 
unit with a two- or four-channel switch, the CPU 
channel interface must vary the CP-owned devices 
if all eight disks in the preceding configuration 
of those disk are CP-owned volumes (such as CP 
CP paging and spooling volumes) , the OS system 
vary the CP-owned volumes offline. This procedure 
CP needs. 



I CHANNEL SWITCHING ON ONE CPU 



I You can also use the two- or four-channel switch for devices attached to 
I one CPU that is running VM/370. For example, one CPU could be running 
I VM/370 with OS running in a VM/370 virtual machine. The configuration 
I is: 
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290-297 
390-397 



I this configuration: 

RDEVICE ADDRESS= (290,8) , DEVTYPE=23 14, FEATDRE = 2CHANSW 

RDEVICE ADDRESS=(390,8) ,DEVTYPE=2314 ,FEAT0RE=2CHANSW 

RCTLUNIT ADDRESS=290,CUTYPE=IFA 

RCTLUNIT ADDRESS=390,COTYPE=IFA 

For this example, you should have all the devices associated with one 
path offline when you load VM/370. Otherwise, the following message is 
displayed : 

DMKCPI954E DASD raddr VOLID volid NOT MOUKTED, 
DUPLICATE OF DASD raddr 



In this example, the 
system running in a v 
virtual machine via the 
in the VM/370 directory, 
machine operating system 
the real machine. Also, 
control of VM/370, and 
access minidisks which 
reserve/release is supp 
minidisks that are not 
channel switching on one 



231U DASD devices can only be used by the OS 

irtual machine if they are dedicated to that 

ATTACH command or the DEDICATE control statement 

The device addresses generated for the virtual 

do not need to be the same as those defined for 

any operating system that is running under the 

using channel switching with VM/370, cannot 

are on devices with channel switching. Because 

orted only for minidisks that are full packs, 

defined as full packs cannot be accessed via 

CPU. 



However, minidisks can be used if one of the channel interfaces is 
using the device as a dedicated device and the other channel interface 
is using reserve/release support. In this example, such support implies 
a full pack minidisk. Suppose that the channel 2 devices are online and 
channel 3 device offline when VM/370 is loaded. Also suppose that 291 
contains a full pack minidisk. When VM/370 is loaded, device 291 is 
considered a CP system device. VM/370 virtual machines can access the 
full pack minidisk at 291, and it has reserve/release protection. Then, 
the OS virtual machine controlling the channel 3 interface can have the 
same pack dedicated to it as 391. The OS virtual machine can only 
access the full pack minidisks as 391; other VM/370 virtual machines can 
only access it as 291. 

As another example, consider channel switching for tapes. If the 
real configuration includes a 2816 Switching Onit or a Two- or 
Four-Channel Switch feature, it can be made to operate under control of 
a virtual machine operating system. For example, if 580 and 680 are the 
alternate device addresses for a particular tape drive, then: 

• Generate the virtual machine operating system for the appropriate 
hardware (in this case a 2816 Switching Unit on channels 5 and 6) . 
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• Generate CP as though 580 and 680 are different devices (with 
different control units and channels) and generate them with the 
Two-Channel Switch feature (FEAT0RE=2CHANSW) . 

• Issue the CP ATTACH command for both device addresses (580 and 680) 
whenever the real device is to be attached to the virtual machine. 

The device addresses generated for the virtual machine operating 
system do not need to be the same as those on the real machine. 

The devices must be used by the virtual machine as dedicated devices 
(attached, or defined with a DEDICATE statement in the VM/370 
directory) . 



OPERATING SYSTEMS USING BESERVEZlJIiJASE 

VM/370 does not include any reserve/release support for virtual machines 
I sharing DASD volumes. If the real configuration includes a Two- or 
Four-Channel Switch feature, reserve/release support can be made to 
operate under control of the virtual machine operating system. In this 
way, a virtual machine can share a DASD volume (either virtual or 
real) . 

For example, if 230 and 330 are alternate device addresses for a 
particular DASD facility to be shared by OSERA and USERB (two virtual 
machines running on the same real computing system) , then: 

• Generate the virtual machine operating system for USERA to support 
the appropriate hardware (device at 230, Two-Channel Switch) and 
software (RESERVE/RELEASE) . 

• Generate the virtual machine operating system for DSERB to support 
the appropriate hardware (device at 330, Two-Channel Switch) and 
software (RESERVE/RELEASE). 

• Generate CP as though 230 and 330 were different devices (with 
I different control units and channels) ; and generate them with the 
i Two-Channel Switch feature (FEAT0RE=2CHANSW) . 

• Issue the CP ATTACH command, attaching device 230 to USERA and device 
330 to USERB. 

If the system generated for USERB is to run in a real machine rather 
than a virtual machine: 

• Generate the CP system with device 230 but not 330. 

• Issue the CP ATTACH command, attaching device 230 to USERA. 

In both cases: 

• The device addressess generated for systems to run in a virtual 
machine do not need to be the same as on the real machine. 

• The devices used by virtual machines must be dedicated (attached or 
defined with a DEDICATE record in the VM/370 directory) . Minidisks 
cannot be shared in this manner. 
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Planning Considerations for Remote 3270s 



VM/370 supports 3270 display units and printers attached to binary 
synchronous comfflunications lines. Both remote cluster and standalone 
configurations are supported. This support includes: 

• Nonswitched point-to-point binary synchronous transmission. 

• A maximum of 32 display stations and/or printers, in any combination, 
attached to each 3271 control unit. 

• A remote 3270 copy function. 

• EBCDIC (Extended Binary Coded Decimal Interchange Code) transmission 
code only. 

• Remote 3270 terminals supported as virtual machine operator 
consoles. 

• CP commands allowing the operator to activate and deactivate the 
teleprocessing lines and remote stations. 

• The CMS Editor support for remote 3270s. 

• The recording of MDR (Miscellaneous Data Recorder) records and OBR 
(Outboard Recording) records on the VM/370 error recording cylinder. 
The MDR records are for the station and the OBR records are for the 
line. The CPEREP program edits and prints these records. 

The 3270 hard-copy support is limited to remote 3270 virtual machine 
consoles. You assign a screen copy function to a 3270 program function 
key. Depressing that key transfers the current display image, in its 
entirety, to an available printer attached to the same control unit. If 
the printer is busy when the copy function is invoked, the virtual 
machine operator receives a NOT ACCEPTED message in the screen's status 
area » 

The following restrictions apply to VM/370' s support of remote 3270s: 

• Remote 3270 terminals cannot be used as primary or alternate VM/370 
system consoles. 

• The number of binary synchronous lines supported by VM/370 for remote 
3270 use is 16 minus the number of 3704/3705 Communications 
Controllers in NCP mode minus one (if there are any 3704/3705 

Communications Controllers in EP mode) . 



I 3270 SUPPORT ON BINARY SYNCHRONOUS LINES 

I The supported display devices on binary synchronous lines have the same 
I flexibility and usefulness as locally attached 3270 devices, except for 
I the following limitations: 

I • Dis£lai Information In^uirj and Retrieval S£eed — Because the 3270 
I remote stations are subject to (1) relatively slow teleprocessing 
I transmission speeds and (2) the mechanics of polling operations. 
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j screen display and data entry are not as rapid for remote 3270 

I devices as they are for locally attached 3270s. 

I • CP DIAL and ATIICH Commands — The CP DIAL and ATTACH commands are 

I not supported for remote 3270 stations. 

I • S§£^ CogY of 3270 Screen Ima^e — Just as users of locally attached 

I 3270 display devices can spool their virtual console input and output 

I to the system printer, so can the users of remote 3270 display 

I devices. However, for remote 3270 users, the terminal is physically 

I distant from the system printer and the printer's output is not 

I readily accessible. To improve accessibility, VM/370 provides, 

I within its 3270 remote support, a limited hard-copy facility at the 

I remote location. 

I • Test Request Key -- The Test Request key on the 3270 terminal is not 

I supported for remote 3270s. 



I HARDWARE CONFIGURATION SUPPORTED 

I VM/370's support of remote 3270s requires: 

I • A binary synchronous line 

I • A control unit 

I • Terminal devices (display stations and/or printers) 

I The binary synchronous line must be in 2701/2703 mode. The 

I transmission control units supporting remote 3270s on binary synchronous 

I lines are: 

I • Integrated Communications Adapter (ICA) . 

I • IBM 2701 Data Adapter Unit with Synchronous Data Adapter Type II. 

I • IBM 2703 Transmission Control with Synchronous Data Adapter Type II. 

I • IBM 3704 and 3705 Communications Controllers in emulation mode. A 

I 3704/3705 line is in emulation mode when it is controlled by the 

I Emulation Program (EP) or the Partitioned Emulation Program (PEP) in 

I EP mode. 

I Cluster and standalone control units are supported for remote 3270s. 

I The IBM 3271 Control Unit, Model 2, supports clusters of up to 32 remote 

I display stations and/or printers. The IBM 3275 Display Station, Model 

I 2, is the standalone 3270 device that can be attached remotely. 

I The following devices can be attached to the 3271 control unit: 

I • IBM 3277 Display Station, Model 2 

I • IBM 3284 Printer, Model 2 

I • IBM 3286 Printer, Model 2 

I • IBM 3288 Line Printer, Model 2 

I The IBM 3275 Display Station, Model 2, is a standalone control unit 

I and display station. You can attach the IBM 3284 Printer, Model 3, to 

I the 3275. In addition, you can attach the IBM 3286 Printer, Model 3, to 

I the 3275 if RPQ MB4317 is installed. 
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I SYSTEM GENERATION REQUIREMENTS 

I When you generate VM/370 you must code the appropriate CLUSTER, 

I TERMINAL, and RDEVICE macros and assemble them as part of the DMKRIO 

I (real I/O configuration) file. Then, after the DMKRIO file assembles 

I successfully, you must make a list of the resource identification codes 

I of all the remote 3270 lines and terminals. Give the list to the 






I this information when they issue the CP commands that control the 
I operation of remote 3270 lines and devices. 



I THE CLUSTER MACRO 

I Code one CLUSTER macro for each 3271 control unit and each 3275 display 
I station. Only a maximum of 16 CLUSTER macros is allowed. Each CLUSTER 
I macro must have a unique label. The CLUSTER macro is described in the 
I "Preparing the Real I/O Configuration File (DMKRIO)" section of "Part 2: 
I Defining Your VM/370 System." 



I THE TERMINAL MACRO 

I Code one TERMINAL macro for each display station and printer that is 
I attached to the clustered 3271 control unit. 

I Code one TERMINAL macro for the 3275 display station. If a 3284 or 
I 3286 printer is attached to the 3275, code M0DEL=3 on the TERMINAL 
I macro. The TERMINAL macro is described in the "Preparing the Real I/O 
I Configuration File (DMKRIO)" section of "Part 2: Defining Your VM/370 
I System." 



I THE RDEVICE MACRO 

Code one RDEVICE macro for each binary synchronous line used for remote 
3270s (code one RDEVICE macro for each CLUSTER macro you code) . A 
maximum of 16 RDEVICE macros for lines to support remote 3270s is 
allowed. 

The RDEVICE macro is described in Part 2. However, the format of the 
RDEVICE macro for the binary synchronous line and transmission control 
unit for remote 3270s is included here to help you code the macro 
correctly. The format of an RDEVICE macro for a communication line that 
supports remote 3270s is: 
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Haae | Operation | Operands 



RDEVICE 



ADDRESS=cuu, 

2701 
2703/ 
HDEVICE=<ICA 

370U' 
3705 

ADAPTER=BSCA 

[ ,BASEADD=cuu ] 

,CLUSTER=label 



where : 
ADDRESS=cuu 

is the real I/O address of the binary synchronous line to be used 

by remote 3270s. 

The address, cuu, is three hexadecimal digits from 000 to FFF. 

2701 

2703, 
DEVT¥PE=<ICA 

37041 

3705 
is the device type of the transmission control unit that controls 
the line. 

Note: The lines attached to the 3704/3705 must be controlled by the 
Emulation Program (EP) or the Partitioned Emulation Program (PEP) 
in EP mode. 

ADAPTER=BSCA 

is the terminal adapter for the transmission control unit. BSCA 
represents the: 

• IBM Binary Synchronous Terminal Adapter Type II for a 2701 

• IBM Binary Synchronous Terminal Control Type II for a 2703 

• Integrated Communications Adapter (ICA) on the System/370 
Model 135 

• IBM 3704 and 3705 Communications Controllers 

BASEADD=CUU 

is the native subchannel address (load address) of the 3704/3705 
that controls the physical line or lines. This operand is required 
for correct operation of VM/370 recovery management for emulator 
lines on a 3704/3705. Specify this operand only for 3704 and 
3705. 

CLUSTER=label 

is the label of a CLUSTER macro that defines the cluster or 
standalone station attached to this line. 
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I The following examples are RDEVICE macros describing a nonswitched 
I point-to-point communication line connected to a 2701, 2703, and 3705. 

I llil£i§ 1' 

I RDEVICE ADDRESS=078 ,DEVT¥PE=2701, ADAFTER^BSCA, CLU3TER=CLu3T001 

I The cluster station that is connected to this line is defined by the 
I CLUSTER macro labeled CLOST001. The line at address 078 is controlled 
I by a 2701 transmission control unit. 

I Example 2 

I RDEVICE ADDRESS=080,DEVTYPE=2703, ADAPTER=BSCA, CLUSTER=CLDST020 

I The line at address 080 is controlled by a 2703 transmission control 
I unit and the corresponding CLUSTER macro is labeled CLUST020. 

I Example 3 

I RDEVICE ADDRESS=0B8,DEVTYPE=3705,ADAPTER=BSCA, X 

I BASEADD=0B0,CLUSTER=CLUST030 

I The line at address 0B8 is controlled by a 3705 Communications 
I Controller and the corresponding CLUSTER macro is labeled CLOST030. 



I THE RESOURCE IDENTIFICATION CODES 

I After the real I/O configuration file (DMKRIO) assembles successfully, 

I generate a list of the resource identification codes that correspond to 

I each line address. Give the list to the operations group. at your 

I installation. The operator needs to know the resource identification 

I code when he issues the commands to control the operation of the remote 

I ~} ^ I \J J.X11CO aiiu i.c;i. ulRu J.S • 

I The resource identification code is a four-digit hexadecimal code. 

I The low-order three digits of the resource identification code are the 

I resource address. The high-order digit is the line code. 

I The resource address is generated by VM/370; the order in which the 

I TERMINAL macros appear in the real I/O configuration file (DMKBIO) 

I determines the resource addresses of the terminals defined. Each 

I CLUSTER macro defines a 3270 control unit; each 3270 control unit has a 

I resource address of X'OO*. The device defined by the first TERMINAL 

I macro after the CLUSTER macro (in the DMKRIO file) has a resource 

I address of X'OI', the second has a resource address of X'02', up to the 

I maximum of X' 20' . This resource address makes up the low-order three 

I digits of the resource identification code. 

I The line code is also generated by VM/370. You have to refer to the 

I assembly listing for DMKRIO to determine the line code (the high-order 

I digit of the resource identification code) . Locate the label DMKRIORN 

I near the end of the DMKRIO assembly listing. This label identifies a 

I list of all the lines used by remote 3270s and by 3704/3705 

I Communications Controllers in NCP mode. The high-order digit is the 

I line code and is assigned according to the order in which the line 

I addresses appear in the list. The first line address is assigned a line 

I code to complete its resource identification code, the second is 

I assigned 1, and so on up to the last line. VM/370 supports a maximum of 
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16 binary synchronous lines for use by remote 3270s, thus the maximum 
value of the high-order digit is F. Figure 13.1 shows you a sample 
DHKBIO assembly listing and the corresponding line codes. 



1 Sample of 


DMKRIO Assembly Listing 


Line 

Code (in 

hexadecimal) 


1 DMKRIORN DC 


F'U' 




1 DC 


AL2((RDV078-DMKRIODV)/8) 




1 DC 


XL2'078« 





1 DC 


AL2 ( (RDV07A-DMKRIODV) /8) 




1 DC 


XL2'07A« 


1 


1 DC 


AL2 ( (RDV079-DMKRIODV) /&) 




1 DC 


XL2'079« 


2 


1 DC 


AL2((RDV07B-DMKRIODV)/8) 




1 DC 


XL2«07B' 


3 



Figure 13.1. Example of Determining Line Code for Remote 3270 Resource 
Identification Codes 



Once you determine the resource identification codes for the devices 
in your remote 3270 configuration, generate a list for operations. The 
list should include the following information: 

• Line address 

• Line code 

• Resource address 

• Label of plug on control unit panel 

• Resource Identification Code 

• Device type 

Hote: The plug panel of the 3271 control unit has up to 32 ports where 
terminals can be attached. Each of these ports is labeled. The first 
port is labeled 0, the second is labeled 2, and so on up to 31. 



I AN EXAMPLE OF A REMOTE 3270 CONFIGURATION 



I This example shows you the contents of the real I/O configuration file 
I to define the following remote 3270 configuration: 

I • A clustered 3271 control unit with eight ports 
I • A standalone 3275 display station 

I The macros are coded so that the 3271 clustered control unit can 
I support eight display devices, or six display devices and two printers. 
I To define such a configuration, you must code 2 CLUSTER, 16 TERMINAL, 
I and 2 RDEVICE macros defining the 2 separate clusters. A 3275 
I standalone control unit, with one display and one printer, is also 
I supported by the following macros. To define it, you must code one 
I CLUSTER, one TERMINAL, and one RDEVICE macro. 
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The real I/O configuration file for this example is: 



DMKRIO 
CLOST078 



CLOST07A 



CLUST079 



CSECT 

CLUSTER CDTYPE=3271,GPOLL=U07F,LIHE=078 

TERMINAL TERM=3277 ,SELECT=6040 ,FEATDRE=OPRDH, M0DEL=2 

TERMINAL TERM=3277,SELECT=60C 1, FEATORE=OPRDR ,M0DEL=2 

TERMINAL TERM=3277 ,SELECT=60C2 ,FEATDRE=OPRDH, M0DEL=2 

TERMINAL TERM=3277 ,SELECT=60C3, FEATORE=OPRDR ,M0DEL=2 

TERMINAL TEHS=3277 , SELECT=60C'I ,FEAT0HE=OPRDH,HODEL=2 

TERMINAL TERM=3277,SELECT=60C5,FEATDRE=OPRDR ,M0DEL=2 

TERMINAL TERM=3286 ,SELECT=60C6 ,M0DEL^2 

TERMINAL TERM=3284, SELECT=60C7,MODEL=2 

CLUSTER CHTYPE=3275,GPOLL=407F,LINE=07A 

TERMINAL TERM=3275,SELECT=6040, FEATURE=OPRDR ,M0DEL=3 

CLUSTER CUTYPE=3271 ,GPOLL=407F,LINE=079 

TERMINAL TERM=3277,SELECT=6040, FEATURE=OPRDR ,M0DEL=2 

TERMINAL TERM=3277,SELECT=60C1 ,FEATURE=OPRDR, M0DEL=2 

TERMINAL TERM=3277,SELECT=60C2, FEATURE=OPRDR ,M0DEL=2 

TERMINAL TERM=3277 , SELECT=60C3 , FEATURE=OPRDR, M0DEL=2 

TERMINAL TERM=3277,SELECT=60C4, FBATURE=OPRDR ,H0DEL=2 

TERMINAL TERM=3277 ,SELECT=60C5,FEATURE=OPRDR, M0DEL=2 

TERMINAL TERM=3277,SELECT=60C6, FEATURE=0PRDR,M0DEL=2 

TERMINAL TERM=3277 , SELECT=60C7 ,FEATURE=OPRDR, M0DEL=2 

RDEVICE ADDRESS=078,DEVTYPE=3705,ADAPTER=BSCA,BASEADD=OBO, X 

CLUSTER=CLUST078 

RDEVICE ADDRESS=07A,DEVTYPE=3705,ADAPTER=BSCA,BASEADD=OBO, X 

CLUSTER=CLUST07A 

RDEVICE ADDRESS=079,DEVTYPE=3705,ADAPTER=BSCA,BASEADD=OBO, X 

CLUSTER=CLUST079 

In this configuration, if the 3271 cluster control unit is on line 078 
there are six display devices and two printers supported. If the 3271 
cluster control unit is on line 079, eight display devices and no 
printers are supported. Display devices can be interchanged among 
resource addresses allocated to display devices and printers can be 
interchanged among resource addresses allocated to printers; but a 
printer cannot be attached at an address defined for a display device, 
and vice versa. 



»-F-»-«i~ *-\s, 



n MiruTn 



list of resources for the operations group. Your list should be similar 
to the list shown in Figure 13.2; it corresponds to the preceding 
example. 
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1 




Label 


of 1 




n 




1 


Plug 


in 1 


Resource 








Control 1 


Identi- 




1 Line | Line 


Resource 


Dnit 




fication 


Device | 


i Address | Code 


Address 


Panel 




Code 


Type 1 


1 078 1 


000 







0000 


cluster 1 




001 







0001 


display | 




002 


1 




0002 


display | 




003 


2 




0003 


display | 




004 


1 3 




0004 


display | 




005 


U 




0005 


display | 




006 


5 




0006 


display | 




007 


6 




0007 


printer | 




008 


7 




0008 


printer | 


1 079 1 2 


000 


_^ 




2000 


cluster 1 




001 







2001 


display | 




002 


1 1 




2002 


display | 




003 


2 




2003 


display | 




004 


1 3 




2004 


display | 




005 


4 




2005 


display | 




006 


1 5 




2006 


display | 




007 


6 




2007 


display | 




008 


1 7 




2008 


display | 


1 07A 1 1 


000 


1 —— 




1000 


cluster 1 




001 


— 




1001 


display | 




1 002 


— 




1002 


printer | 


1 B9£ei T*ie line code : 


Ls determinec 


1 by re 


Eering 


to Figure 


13.1; 1 


1 it corresponds to thij 


3 example. 










1 , . 










1 



Figure 13.2. Sample List of Resource Identification Codes for Operations 
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Generating a VM/370 System that Supports the 3704/3705 



The generation of a 3704 or 3705 Communications Controller control 
program that runs under the control of VM/370 is normally done after the 
VM/370 system generation is completed. However, when a 3704 or 3705 is 
to be generated, the following preparations must be made: 

• An RDEVICE macro instruction for the 3704 or 3705 must be included in 
the real I/O configuration (DMKRIO) file, 

» 3704/3705 control programs that are to be used by VM/370 must be 
stored on a CP-owned volume in the page format that is currently used 
for saved virtual machine systems (that is, those created by the 
SAVESYS command). Each 3704/3705 control program image to be saved 
must be defined by a NAMENCP macro instruction in the system name 
table (CP module DMKSMT) and saved with the SAVENCP command. 

• Enough space to contain the 3704/3705 control program image must be 
allocated on the CP-owned volume specified in the NAMENCP macro 
instruction. 

I 52le* The alternate console for VM/370 must not be on a 
I telecommunications line on a real 3704/3705, unless the 3704/3705 is 
I loaded by another operating system (OS/VSl, 0S/VS2, or DOS/VS) before 
I VM/370 is loaded. 

Part 4 contains a complete discussion on generating a 3704 or 3705 

I control program. It describes the support provided with NCP, EP, and 

I PEP control programs and tells you how to generate the 3704/3705 control 
I program, step by step. 



CODING THE RDEVICE MACRO 

The RDEVICE macro is described in Part 2. However, the format of the 

RDEVICE macro for a 3704/3705 is included here to help you code the 

macro correctly. The format of the RDEVICE macro for an IBM 3704/3705 
is: 
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Name (Operation i Operands 



RDEVICE 



ADDRESS= 



DEVTYPB= 



( cuu 1 

t (cuu,nn) ), 

/370U) 
13705/, 



ADAPTER=| TYPE1 

TYPE2 

IBM1 

ITELE2 

BSCA 



,MODEL=/ 1 \ I |,SETADDR=| 
2 
3 

5 
6 

7 
8 



r T 

|,CPTYPE=(EP ) I [,CPNAME=ncpname] 
I <NCP> I 

I (pep) I 

t J 

[ ,MAXDIAL=nn] [ , BASEADD=ccu ] 



where: 



ADDRESS= 



(cuu ) 

\ (cuu,nn) j 



I DEVTYPE= 



/3704\ 
13705) 



ADAPTER=| TYEE1 
TYPE2, 
IBM1 
TELE2' 
BSCA 



MODEL=j 



is the real device address (cuu) of the 3704/3705. Use 
the (cuu,nn) form to generate multiple (nn) real device 
blocks (RDEVBLOKs) when CPTYPE=PEP (or EP) is 
specified. 

is the device type. You should specify 3704 or 
3705 instead of 2701, 2702, or 2703 when CPTYPE = PEP 
or EP. 

identifies either the channel adapter accessed by the 

specified real address (TYPE1 or TYPE2) , or a line 

adapter if this is an emulator line group (IBM1, TELE2, 
or BSCA) . 



is the 3704/3705 model number. The model determines the 
size of the 3704/3705 storage. See Figure 14 for a list 
of the model numbers and the corresponding storage sizes, 
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IBM 3704 Communications 
Controller 



IBM 3705 Communications Controller 



A1 
A2 
A3 
A4 



16K 
32K 
48K 
6UK 



Model 




Storage 


A1, B1, C1, 


B1 


16K 


A2, B2, C2, 


D2 


48K 


B3, C3, 


D3 


8CK 


B4, C4, 


D4 


112K 


C5, 


D5 


144K 


C6, 


D6 


176K 




D7 


208K 




D8 


240K 



Figure 14. IBM 3704/3705 Models 



SETADDR=| 
1 
2 
3 
4 



indicates which set address (SAD) command must be 
issued prior to enabling the emulator lines. 



CPTYPE= 



(IP ) 

{ncp> 
( pep) 



indicates which type of 3704/3705 control program is 
run in this 3704/3705. If any of the three may be run, 
omit the CPTYPE operand, or specify CPTYPE=EP. If 
CPTYPE=NCP is specified, an emulator program may not 
load successfully. 



CPNAME=ncpname 



is the one- to eight-character name of the control 
program to be automatically loaded in the 3704/3705 at 
system IPL time. If an automatic load is not desired, 
omit this operand. 



MAXDIAL=nn 



is the maximum number of dynamically specified 

2701/2702/2703 emulator lines which may be active at 

any one time, "nn" additional BDEVBLOKs are generated 
to accommodate the emulation lines. 

This operand is valid only if CPTYPE=PEP. 



BASEADD=ccu is the native address (load address) of the 3704/3705 
which controls the physical line (s) . This operand is 
reguired for correct operation of VM/370 recovery 
management for emulator lines based on a 3704/3705. 

This operand is valid only if ADAPTER=IBM1 , TELE2, or 
BSCA. 
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SPECIAL CONSIDEBATIONS FOR CODING THE RDEVICE MACRO 

The 3704/3705 Conaunications Controllers have many varied uses. 
Consequently, the control program generation for the 3704/3705 is 
complex. 



EPzO^il Control Proarams 

If the 3704/3705 is to be run in emulation mode: 

• Use the (cuu,nn) form of the ADDRESS operand to generate multiple 
RDEVBLOKs. 

• Omit the CPTYPE and MAXDIAL operands. 

• Specify the appropriate name for CPNAME. 

To generate additional emulator lines for the same 3704/3705, use the 
following coding guidelines on subsequent RDEVICE macros: 

• Omit the CPTYPE, CPNAME, MAXDIAL, and MODEL operands. 

• Specify the ADAPTER as IBM1, TELE2, or BSCA, as appropriate. 

For ADAPTER=IBM1 (or TELE2) , the SETADDR operand must also be 
specified, exactly as if the device were a 2702 or 2703. Special care 
must be taken to ensure that the CPNAME and ADAPTER operands appear only 
in one RDEVICE macro for each physical 3704/3705. 

E2te* If you use the (cuu,nn) form of the ADDRESS operand to generate 

multiple RDEVBLOKs and also specify the CPNAME and ADAPTER=TYPE1 

operands on the RDEVICE macro, the additional RDEVBLOKs are generated as 
ADAPTER=IBM1 and SETADDR=4. 



Z2E NCP-Only Control Programs 

If the 3704/3705 is only to be used with the NCP: 

• Specify CPTYPE=NCP. 

• Omit the MAXDIAL and SETADDR operands. 

• Specify either ADAPTER=TYPE1 (or TYPE2) . 

This prohibits the use of virtual 2701/2702/2703 lines via the 3704/3705 
(unless separate RDEVICE macros are used to generate additional 
RDEVBLOKs). In addition, be sure that the CPNAME and ADAPTER operands 
appear only in one RDEVICE macro for each physical 3704/3705. 
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I2E PEP Control Programs 

If CPTYPE=PEP is specified, the necessary RDEVICE operands depend on the 
■anner in which the PEP is to be used: 

• If all of the 3704/3705 lines are specified as initially in NCP mode 
(USE=NCP on the LINE macro in the 370U/3705 Stage 1 input file, or 
USE operand omitted) , the HAXDIAL operand must be used to generate 
additional RDEVBLOKs. The number to be generated is a consideration 
of fixed storage requirements (each RDEVBLOK requires 80 bytes of 
fixed storage) and the 2701/2702/2703 capabilities. The number 
specified for MAXDIAL is an absolute limit on the number of 
2701/2702/2703 emulation lines which can be active at any one time, 
regardless of how many lines are specified as TYPE=PEP in the 
3704/3705 control program generation. 

• If no lines were specified as TYPE=PEP in the 3704/3705 generation 

(that is, all lines are specified as either TYPE=NCP or EP) , use the 
(cuu,nn) form to define the RDEVBLOKs for the emulator lines, and 
omit the HAXDIAL operand. 

Note: If you use the (cuu,nn) form of the ADDRESS operand to generate 
multiple RDEVBLOKs and also specify the CPNAME and ADAPTER=TYPE1 
operands on the RDEVICE macro, the additional RDEVBLOKs are generated 
as ADAPTER=IBM1 and SETADDR=4. 

• If the 3704/3705 generation includes a mixture of the NCP and PEP 
lines (that is, the corresponding LINE macros have a combination of 
TYPE=NCP, EP, and PEP) , use the ADDRESS operand to generate 
emulator-only lines and use the MAXDIAL operand to specify a limit on 
how many PEP lines can be varied to emulation mode (these are in 
addition to the emulator-only lines) . 

• If you specify TYPE=PEP and USE=EP, the lines generated in this 
fashion cannot be used as NCP lines by VM/370 without explicit 
operator action. 

Summary of RDEVICE Ma2£2 Codincf Considerations 

For each physical 3704/3705, there should be only one RDEVICE macro 
which specifies the ADAPTER=TYPE1 or TYPE2, MODEL, CPTYPE, MAXDIAL, and 
CPNAME operands. This RDEVICE macro defines the base address of the 
3704/3705 (that is, the real address used to perform the load and dump 
operations) . If the physical device is a 3705 with two channel adapters 
installed, there may be a second RDEVICE macro which specifies the 
ADAPTER=TYPE1 or TYPE2, MODEL, and CPTYPE operands. There must never be 
a second use of the CPNAME operand; the MAXDIAL operand need not be 
coded twice since a 3705 cannot have two TYPE1 channel adapters. Even 
if CPTYPE=EP is specified, the 3704/3705 base address cannot be used as 
a telecommunications line; its function is only to load and dump the 
3704/3705, and the device type and class are different from those of all 
other lines generated. 

Whenever there is more than one subchannel address (CPTYPE=EP or 
PEP) , include in the DMKRIO deck all of the RCTLUNIT macros required to 
specify those real addresses which the EP or PEP control program may 
use. For example, assume all of the lines on a 3704/3705 are specified 
as TYPE=PEP, the MAXDIAL number is specified as 10, and the real 
addresses for the 3704/3705 are 020 (base address) and 021-07F. In this 
case, a RCTLUNIT macro must be included to cover the device address 
range 020-07F, even though no more than ten emulator lines could be 
active at one time. 
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If you have a 3704/3705 and a 2701/2702/2703 on the same VM/370 
system, the virtual addresses for the 370*^/3705 must not be the same as 
any of the real 2701/2702/2703 addresses. 



Examples 

Examples of BDEVICE macro specifications follow. For convenience, the 
continuation character in position 72 is not shown. 

Exaffl£le_2 

RDEVICE ADDRESS=320, 
DEVTYPE=3705, 
M0DEL=4, 
ADAPTER=TYPE2, 
CPTYPE=NCP, 
CPHAME=NCP320 

This describes a 3705 Model B4 (112K storage) at address X«320», with 
a type two channel adapter. The 3705 is to be automatically loaded 
with the Network Control Program •NCP320*. 

Jxam£le_2 

RDEVICE ADDRESS= (020,16) , 
DEVTyPE=3704, 
M0DEL=2, 
ADAPTER=TYPE1, 
CPMAME=CEP020 

This describes a 32K 370U at address X»020», with 15 emulator lines 
at addresses X»021« to X»02F«. The 3704 is to be loaded with the 
Emulation Program •CEP020'. 

Exam£le_3 

RDEVICE ADDRESS= (030,16) , 
DEVTYPE=370a, 
ADAPTER=IBM1, 
SETADDR=2, 
EASEADD=020 

This describes an additional 16 emulator lines on the same 3704 
specified by Example 2. 
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Exam£le_4 

RDEVICE ADDRESS=OBO, 
DEVTYPE=3705, 
M0DEL=4, 
ADAPTER=TYPE1, 
CPTYPE=PEP, 
CPNAME=PEP0B0, 
MAXDIAL=16 

RDEVICE ADDRESS= (0B1,15) , 
DEVTYPE=3705, 
ADAPTER=BSCA, 
BASEADD=OBO 

These two macros describe a 112K 3705 for use with the Partitioned 
Emulation Program 'PEPOBO', at base address X'OBO', with a maximum of 
16 start/stop emulator lines (switched mode) , and 15 binary 
synchronous lines (always in emulator mode) at addresses X'OBI' to 
X»OBF' . 



CRJiTING AN ENTRY IN THE SYSTEM NAME TABLE 

You must create an entry in the system name table (DMKSNT) for each 
unique 370U/3705 control program that you generate. If you can foresee 
generating several versions of the 3704/3705 control program, define 
extra entries in the system name table when you generate VM/370. In this 
way, you do not have to regenerate the VM/370 system just to update the 
system name table. If you should have to regenerate the VM/370 system 
just to add a new entry to the system name table, see the discussion 
about the GENERATE EXEC procedure in "Part 6: Updating VM/370." 

The NAMENCP macro is described in Part 2. 



RESERVING DASD SPACE FOR THE 3704/3705 CONTROL PROGRAM IMAGE 

DASD space to contain the 3704/3705 control program image must be 
reserved on a CP-owned volume. The DASD space reserved should be 
sufficient to contain the number of pages specified in the SYSPGCT 
operand of the NAMENCP macro, plus one or more for system use, as 
follows: 

• If CPTYPE=EP, allow only one extra page. 

• If CPTYPE=NCP or PEP, allow one extra page for the first 1000 
resource IDs defined, and one additional page for each additional 
1000. The number of resource IDs defined can be determined from the 
output listing of the 'fnameOI' Stage 2 assembly. The extra page 
requirements never exceed a total of four pages. 

These additional pages are used to store the reference table 
information provided by the SAVENCP program. The page-record capacity 
for one cylinder of DASD space on differing device types is in the 
"Formatting Volumes — General Information" section of Appendix F. 
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I Saved Systems 



Saved systems are described in detail in the VM/370: Sj^stem Programmer's 
Guide. If you plan to save core-image copies of virtual machine 
operating systems you should do the following when you generate VM/370. 

• Create an entry in the system name table for each system you wish to 
save. 

• Reserve space on a CP-owned volume for each system you wish to save. 

You create entries in the system name table by coding NAMESYS and 
NAMEMCP macros and assembling the system name table (DMKSNT) file during 
system generation. You specify which volumes are to be owned by CP by 
coding the SYSOWN macro and assembling the CP system control (DMKSYS) 
file during system generation. These macros and files are described in 
Part 2. 

If you decide to add entries to the system name table after you have 
installed VM/370, you must code the appropriate NAMESYS or NAMENCP 
macros, reassemble the system name table module (DMKSNT) , and reload the 
CP nucleus. Likewise, if you must add a CP-owned volume after system 
generation, you must recode the SYSOWN macro, reassemble the CP system 
control module (DMKSYS) , and reload the CP nucleus. Use the GENERATE 
EXEC procedure to reassemble DMKSNT and/or DMKSYS and to reload the CP 
nucleus. GENERATE is described in "Part 6: Updating VM/370." 
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Estimating VM/370 Storage Requirements 



This section contains information about: 

• Estimating real storage requirements for VM/370 

• Reducing the size of the CP nucleus 

• Estimating uirect access storage requirements 

• Estimating storage requirements for CMS minidisks 

The "Specifying a Virtual=Real Machine" section includes information 
about estimating real storage requirements for a virtual=real machine. 

Mhh STORAGE REQUIREMENTS FOR CP 

The following chart lists the various CP requirements and the amount of 
real storage required for each. 



CP Requirement | Real Storage Allocated 


Resident nucleus | Approximately 132K 


Internal trace table | 4K of storage is allocated for each 256K of 

1 real storage. This storage is set aside 
1 at IPL time. 


Real control blocks | There is a control block for each real 

1 device, control unit, and channel: 
1 • 80 bytes/real device 
1 • 64 bytes/real control unit 
j • 96 bytes/real channel 

1 • 24 bytes for each remote 3270 or real 
1 3704/3705 


Permanently allocated | A minimum of 12K, plus an additional 
free storage | 4K for each 64 K of real storage above 
(virtual control | 256K. This storage is set aside at IPL 
blocks and tables) | time. Each logged-on virtual machine 

1 requires a virtual machine control block 
1 (VMBLOK) , a segment table (SEGTABLE) , 
1 a page table (PAGTABLE) , a swap table 
1 (SMPTABLE) , and a control block for each 
1 virtual device, control unit, and channel. 
1 The storage required is: 

1 • 400 bytes for the VMBLOK 

1 • 64 bytes/1 M of virtual storage for 

1 the SEGTABLE 

1 •40 bytes/64 K of virtual storage for 

1 the PAGTABLE 

1 • 136 bytes/64K of virtual storage for 

1 the SWPTABLE 

1 • 56 bytes/virtual device 

1 • 40 bytes/virtual control unit 

1 • 40 bytes/virtual channel 
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For example, if you have: 

1M of real storage 
29 real devices 

6 real control units 

3 real channels 

and 12 virtual machines defined, each with: 

1 virtual reader 

1 virtual printer 

1 virtual punch 

3 virtual disks 

3 virtual channels 

1 virtual machine console 

3 virtual control units 

320K of virtual storage 

you would estimate CP real storage reguirements as follows. 

132K for the CP resident nucleus 
16K for the CP internal trace table 
3K for the real control blocks, calculated as follows: 

80 X 29 = 2320 bytes for the real devices 

64 X 6 = 384 bytes for the real control units 

96 X 3 = 288 bytes for the real channels 

the sum is: 2320 + 384 ♦ 288 = 2992 bytes 
(approximately 3K) 

60K for permanently allocated free storage 

21 IK real storage reguired 

Also, as each of the 12 virtual machines defined logs on, approximately 
2K of real storage is allocated to each from the permanently allocated 
free storage. 

400 bytes for a VMBLOK 

64 bytes for the SEGTABLE 
200 bytes for the PAGTABLE 
680 bytes for the SWPTABLE 

56 bytes for a virtual reader 

56 bytes for a virtual printer 

56 bytes for a virtual punch 
168 bytes for three virtual disks 
120 bytes for three virtual channels 

56 bytes for a virtual machine console 
120 bytes for three virtual control units 

1976 bytes for each of the logged-on users defined 

See the "Specifying the Amount of Virtual=Real Space" section for an 
example of estimating storage reguirements and determining the maximum 
size of the virtual=real area. 
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REDUCING THE SIZE OF THE CP NUCLEUS 

Support for the 3704, 3705, 3066, and 3270 increases the size of the CP 

nucleus. The 3704/3705 is primarily handled by the module DMKRNH. The 

I graphic device support for locally attached terminals is handled by the 

I module DMKGBF while the remote 3270 support is handled by the DMKRGF and 

I DMKBSC modules. Each of these modules occupies approximately 6000 bytes 

(decimal) of system nucleus space. 

I This nucleus area can be reclaimed by deleting DMKRNH, DMKGRF, DMKRGF 
I and DMKBSC from the system loadlist EXEC file. Caution should be 

exercised before deleting them from the loadlist. If you generate any 
I type of locally attached graphic device in the DMKRIO assemble file, you 
I cannot delete the module DMKGRF. Or, if you generate remote 3270s in 
I the DMKRIO assemble file, you cannot delete the DMKRGF and DMKBSC 
I modules. In addition, if you generate the 3704/3705 in the DMKRIO 

assemble file, you cannot delete the DMKRNH module. 

The following names are undefined during the VMFLOAD procedure if 
DMKGRF and DMKRNH are deleted from the loadlist: 

DMKGRFEN DMKRNHCT DMKRNHND 
DMKGRFIC DMKRNHIC DMKRNHTR 
DMKGRFIN DMKRNHIN 

I The following names are undefined during the VMFLOAD procedure if 
I DMKBSC and DMKRGF are deleted from the loadlist: 

I DMKBSCER DMKRGFIC 
I DHKRGFEN DMKRGFIN 



DIRECT ACCESS STORAGE REQUIREMENTS FOR CP 

The following list shows how much DASD space CP requires by DASD type. 
The following paragraphs describe in detail how you determine the amount 
of DASD space CP requires for the nucleus, error recording, warm start 
data, directory, saved systems data, paging and spooling space. 



CP Nucleus 
Error Recording 
Warm Start 
Directory 
Saved Systems 
Paging Space 
Spooling Space 

Total System! 90 cyl 55 cyl 49 cyl 120 cyl 
iThese figures do not include space for saved systems. 

CP NUCLEUS DASD REQUIREMENTS 

The CP nucleus (without a virtual=real area) currently requires 75 to 80 
pages of disk space for resident and pageable functions. 
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50 
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70 
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To determine the nuaber of cylinders required for the CP nucleus, 
refer to the load aap produced during system generation. One DASD page 
is required for each page of fixed and pageable nucleus (for a CP 
nucleus without a virtual=real area) . The formulas for the amount of 
DASD space needed for a CP nucleus with a virtual=real area are in the 
••Specifying a Virtual=Real Machine" section. 

For example, if the last module entry in the load map is at page 4B 
(hexadecimal) , 75 pages of disk space are required for CP nucleus 
residence. The number of cylinders required depends on the system 
residence device used; see the "Saved System DASD Requirements" section 
that follows for the number of pages per cylinder each device can 
accommodate. 



xs; 



Normally, the number of cylinders required for CP nucleus residence 

4 cylinders on a 2305 or 3340 
3 cylinders on a 231U or 2319 
2 cylinders on a 3330 or 3333 



ERROR RECORDING DASD REQUIREMENTS 

Error Recording space is fixed and must be allocated as shown (two 
cylinders) . 



HARM START DATA DASD REQUIREMENTS 

Formulas for calculating the amount of warm start space needed are in 
"Part 2: Defining Your VM/370 System" under the discussion of the SYSHRM 
operand of the SYSRES macro. 



VM/370 DIRECTORY DASD REQUIREMENTS 

The VM/370 directory normally requires two cylinders so that it can be 
rewritten without disturbing the active directory and swapped after a 
successful update. Formulas for computing directory sizes are found in 
the "Allocating DASD Space for the VM/370 Directory" section of Part 2. 



SAVED SYSTEM DASD REQUIREMENTS 

Saved systems require one page for each page saved, plus an additional 
information page. However, a 3704/3705 may require up to four 
additional information pages. 

To save one copy of the CMS system requires two cylinders on a 2314, 
2319, or 3340, or one cylinder on a 3330 or 3333. 
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PAGING AND SPOOLING DASD REQUIREMENTS 

Paging and spooling space reguirements are installation-dependent. (The 
values shown in the preceding list are for average systems.) Paging 
space is allocated at a rate of: 

24 pages/cylinder on a 2305 or 3340 
32 pages/cylinder on a 2314 or 2319 
57 pages/cylinder on a 3330 or 3333 
(The 2305 is normally used for paging only.) 
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Spooling data is placed in a 4K-byte buffer with the necessary 
channel programs required for each record. Data capacity of spooling 
cylinders thus varies with the data and CCWs used. 

I The primary system operator is warned when the paging/spooling space 
I becomes 90% full. The VM^370: 0£erator2.s Guide tells the operator what 
I he should do if this warning occurs. 



The following information is intended to help you allocate sufficient 
direct access storage space for CMS minidisks. 

A 2314 cylinder formatted by the CMS FORMAT command contains 150 
800-byte blocks, which can contain approximately 1300 80-byte lines of 
source programs and data. 

A 3330 cylinder formatted by the CMS FORMAT command contains 266 
800-byte blocks, which can contain approximately 2300 80-byte lines of 
source programs and data. 

I A 3340 cylinder formatted by the CMS FORMAT command contains 96 
I 800-byte blocks, which can contain approximately 960 80-byte lines of 
I source programs and data. 

Each 800-byte block contains file control information as well as your 
data. A given amount of data requires more file information if put into 
many small files instead of a few large files. 

For each an average CMS user, the following minidisk space should be 
sufficient: 

• 7 cylinders of 2314 space (for approximately 9100 80-byte lines of 
source programs and data) 

• 4 cylinders of 3330 space (for approximately 9600 80-byte lines of 
source programs and data) 

I • 11 cylinders of 3340 space (for approximately 10560 80-byte lines of 
I source programs and data) 
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The external storage requireaents of multiple virtual machines executing 
concurrently would be excessive if each virtual machine were assigned 
one real direct access storage device for each virtual DASD device in 
its configuration. 

Therefore, if you do not require the full capacity of a real DASD 
device, you can be assigned one or more minidisks instead. A minidisk 
is a logical subdivision of a physical disk pack with its own virtual 
device address, virtual cylinders (starting with 0, 1, 2, and so on) and 
a VTOC (volume table of contents or disk label identifier) . Each of 
your minidisks is preallocated the number of contiguous full cylinders 
you are apt to require, and that space is considered to be a complete 
virtual disk device. 

I Minidisks are controlled and managed by CP. If a virtual machine 

I attempts to use DASD space beyond the boundaries defined for its 

I minidisks, CP presents a command reject (seek check) to the virtual 

I machine. If a system is to be run on both a virtual and a real machine, 

VM/370 recommends that minidisks not be used for that system unless the 

minidisk starts at real cylinder zero. For a detailed list of minidisk 

restrictions, see the YM/370: Introduction. 

I The remainder of this section describes the following characteristics 
I of minidisks: 

I • Definition 

I • Space allocation 

I • Track characteristics 

I • Alternate tracks 

I • Labels 



I PlIIJIM MINIDISKS 

I Permanent minidisks are defined in the VM/370 directory entry for a 

I virtual machine. A minidisk defined in the directory is a permanent 

I part of the virtual machine configuration and the data on the minidisk 

I is available to the user from session to session. 

I If any virtual machine has a temporary requirement for direct access 

I space, this can be filled from a pool of T-disk space. You specify the 

I size of the T-disk pool when you allocate disk space with the standalone 

I Format/Allocate program. Minidisks created from the T-disk area are 

I available to the virtual machine for the duration of one terminal 

I session. When the virtual machine logs off or issues a CP command to 

I release the temporary minidisk, the area is returned to CP. 

I It is up to you to allocate minidisks on VM/370 disks in a manner 

I that minimizes arm contention and physical overlap. Information about 

I minimizing arm contention is found in the "Preparing the CP System 

I Control File (DMKSYS) " section of Part 2. 
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Figure 15 illustrates the use and definition of minidisks. The disk 
labeled 0SD0S1 contains several minidisks, some formatted to OS 
requirements and others to DOS requirements. 0SD0S1 is a 2314 volume. 
The directory entry for userid ABC (an OS user) describes the virtual 
device 230 as a 50-cylinder area, and the virtual device 231 as a 
20^cjlinuer area on real volume 03D031. The directory entry for userid 
XYZ (a DOS user) describes the virtual device 130 as a 50-cylinder disk 
area on a real volume 0SD0S1. 



Real 
Cylinder 
Number 



Virtual 
Cylinder 
Number 




0SD0S1 



DOSRES 



-MFTWRK 



\JMI210 User Directory Entry for user ABC (An OS user) 



USER ABC 

ACCOUNT 985 



123 



512K 



CONSOLE 


E 009 


3215 




MDISK 


230 


2314 


000 050 0SD0S1 W 


MDISK 


231 


2314 


100 020 0SD0S1W 


MDISK 


232 


2314 


031 030 CPVOL 1 W 


SPOOL 


OOC 


2540 


READER A 


SPOOL 


OOD 


2540 


PUNCH A 


SPOOL 


OOE 


1403 


A 



Real 
Cylinder 
Number 



Virtual 
Cylinder 
Number 




DOS LIBRARIES 




■DOSLIB 



■ MFTSUB 



VM/370 User Directory Entry for user XYZ (A DOS user) 



USER XYZ PASSWORD 




ACCOUNT NUMBER 


BIN14 


CONSOLE 


OIF 


3215 


SPOOL 


C 


2540 READER 


SPOOL 


D 


2540 PUNCH 


SPOOL 


E 


1403 


MDISK 


130 


2314 050 050 0SD0S1 W 


MDISK 


131 


2314 001 020 CPV0L1 W 



Note: VM/370 allows cylinders normally reserved for alternate track assignment (cylinders 200 to 202 on 2319 and 2314 disks, 
cylinder 349 on a 3348 Data Module - Model 35, and cylinders 696 and 697 on a 3348 Data Module - Models 70 and 70F) to 
be optionally used for normal data storage if included within the limits of a minidisk. 



Figure 15. Use and Definition of Minidisks 
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The real volume CPV0L1 also contains disk areas assigned to userid 
ABC (virtual device address 232) and userid XYZ (virtual device address 
131) . 

I jjote: On a 3330 or 33U0, an OS ninidisk can only start at real cylinder 
0. See the list of VM/370 restrictions in the VM/370: Introduction for 
more information and explanation of 3330 restrictions. 



MINIDISK SPACE ALLOCATIOH 

OS bases all of its space allocation parameters on the Volume Table Of 
Contents (VTOC) label written on each disk; it determines the amount of 
space available on that volume from the format 5 (space accounting) data 
set control block. Thus, for OS to support minidisks, a VTOC must be 
written whose space accounting data set control block (DSCB) is equal to 
the desired size of the minidisk. The remainder of the disk space on 
the real disk appears to OS to be permanently dedicated, and not 
assignable by the OS space accounting routines. The IBCDASDI service 
program should be used to format minidisks for use by OS or DOS. 

DOS space allocation is specified in the XTEHT job control card. It 
is your responsibility to see that the XTENT cards refer to valid 
minidisk cylinders. On a 2314 or 2319 volume, the last cylinder of any 
minidisk initialized by IBCDASDI is always reserved for use as an 
alternate track cylinder. For example, if you are specifying a 
ten-cylinder minidisk, the XTENT card must refer to cylinders through 
8 only. This leaves the last cylinder for alternate track assignment. 

However, on a 3330, 3333 or 3340 volume, IBCDASDI does not reserve 
alternate tracks. Therefore, a ten-cylinder minidisk must be defined in 
the XTEHT card as cylinders through 9. 

A minidisk always begins at virtual cylinder zero. Its minimum size 
is one cylinder. A minidisk must exist on its real counterpart, that 
is, a virtual 2314/2319 minidisk must reside on a real 2314/2319. 

VH/370 controls the boundaries of minidisks. If an attempt is made 
to refer to a DASD address outside these boundaries, CP presents a 
command reject (seek check) I/O error to the virtual machine. 



TRACK CHARACTERISTICS 

Like real disks, minidisks must be formatted for use by the appropriate 
service program. A minidisk is initialized for use by executing one of 
the following service programs in a virtual machine: 

• For CMS disks, the CMS FORMAT command formats the specified tracks 
into 800-byte blocks or physical records. 

• For CP disks, the standalone CP FORMAT program must be used to format 
specified tracks into 4096-byte blocks. 

• For OS and DOS disks, the IBCDASDI service program writes read-only 
track descriptor records for each track, and clears the remaining 
portion of each track to binary zeroes. It also writes a Format 5 
DSCB whose contents are the minidisk size. 
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Minidisks defined in the VM/370 directory are initialized only once; 
temporary minidisks must be initialized each time they are used. 



ALTERNATE TBACKS 



3330 DISKS 



Alternate tracks flagged at the factory are automatically handled on the 
3330 by the control unit. Alternate tracks on a 3330 cannot be assigned 
in the field. Minidisks on the 3330 Model 1 or 2 should be specified on 
cylinder through cylinder U03 only. The remaining cylinders (404 to 
Ull) are automatically used by the 3830 Control unit for alternate 
tracks. Minidisks on the 3330 Model 11 can be specified on cylinder 
through cylinder 807. 



2314, 2319, AHD 3340 DISKS 

On 2314, 2319, and 3340 devices, CP and CMS do not recognize or support 

standard alternate track techniques for their own use. DOS and OS 

minidisks, however, do recognize and support alternate tracks. The 

IBCDASDI service program automatically assigns the last cylinder in any 

minidisk as an alternate track cylinder. When you initialize 2314/2319 

devices, you can assign all 203 cylinders for virtual machine and system 

I use. And for a 3340, you can initialize up to 682 cylinders, depending 

I on the model. For a 3348 Data Module, Model 35, you can assign the 

I entire disk, 349 cylinders. For a 3348 Data Module, Model 70, you can 

I assign up to 682 cylinders. 

If a track assigned to a virtual machine minidisk area subsequently 
becomes defective, you can: 

• Run the standalone CP FORMAT service program and flag the whole 
cylinder containing the defective track as permanently assigned 

(PERM) . This prevents CP from ever allocating that cylinder for CP 

paging, spooling, or temporary files. You must remember not to 

include this cylinder when you allocate disk space for any virtual 
machine's minidisk in the VM/370 directory. 

• If the minidisk is used by either DOS or OS, reformat the minidisk 
(including the defective track) with the IBCDASDI service program. An 

alternate track is assigned at the end of the minidisk. 

• Set up the entire pack containing the defective track as an OS or DOS 
pack and format it with either IBCDASDI, lEHDASDI, or lEHDASDR for OS 
disks, or with the DOS Initialize Disk utility program (INPP) for DOS 
disks. Alternate tracks are assigned in the standard manner. 



LABELS 

All disks to be handled by CP (as an entity or as a combination of 
logical disks) must have a label on real cylinder 0, track 0, record 3. 
This label identifies the physical volume to VM/370 and must be in the 
form 
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VOL Ixxxxxx 

— or — 

CMS=xxxxxx 

where xxxxxx is a six-character volume label. 

In addition, all virtual machine minidisks should have a label at 
virtual cylinder 0, track 0, record 3. Labels created by IBCDASDI, 
lEHDASDR, or INPP are in the form 

VOLIxxxxxx 

where xxxxxx is a six-character volume label. 

A physical volume that holds only virtual machine minidisks can have 
the first of those minidisks starting at real cylinder, 0. CP recognizes 
the physical volume if the first minidisk has a valid label. 

In Figure 15, the volume indicated as 0SD0S1 has its real cylinder 
allocated to a minidisk which is formatted for use by OS. The volume 
serial number of that minidisk must be 0SD0S1, the label that is 
associated with the real volume. Since the minidisk label identifies the 
physical volume, changing it affects the directory entries of all users 
who have minidisks on that volume. 

I You should not assign real cylinder to a user as a data area, 
I because that user (if he has read/write access to the disk) can rewrite 
I the label on the minidisk. 

Additionally, you must not assign user minidisks to begin on real 
cylinder of any physical volumes which are to contain CP controlled 
areas (for paging, spooling, and so on) . On these volumes, cylinder 
track record 4 contains control information reguired by CP. The VTOC 
labels written are compatible with OS, but indicate to OS that there is 
no space on that DASD storage device. The initialization programs used 
to format OS and DOS minidisks write over and destroy this necessary 
control information if the space is assigned to a user minidisk, and 
this causes CP system failures. 



I SHARING MINIDISKS 

A minidisk can be shared by multiple virtual machines. One virtual 

machine is designated the owner of the minidisk (it has an MDISK control 

statement in its VM/370 directory entry describing the minidisk) and 
other virtual machines can link to the minidisk. 

For example, assume a virtual machine called USEBA owns a minidisk at 
194. The VM/370 directory entry for USERA contains the following 
statements: 

MDISK 194 2314 050 010 SYS003 R READPASS 

USERA's virtual disk is on the volume labeled SYS003, real cylinders 
050-059. 

Now, any other virtual machine that issues the LINK command or has 
the following LINK statement in its VM/370 directory entry can read the 
194 minidisk belonging to USERA. 

LINK USERA 194 CUU B 
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The cuu is the virtual device address at which the 194 minidisk 
belonging to USEBA is linked to another virtual machine. If you define 
another virtual machine, USEBB, with the following statement in its 
VM/370 directory entry: 

LINK USEBA 194 195 B 

OSEBB reads data from DSEBA*s 194 virtual disk whenever it issues a read 
for data on its own 195 virtual disk. 

You can link to any minidisk that is defined in the VM/370 directory 
if that minidisk has a read and/or write password defined in the 
directory and if the type of link you desire is allowed. Three types of 
sharing may exist and, correspondingly, three passwords may be specified 
in the MDISK record. 

Bead-only (B) indicates that all virtual machines sharing the disk 
are using it in read status. 

Bead/write (M) indicates that multiple virtual machines may have read 
access at the same time. 

Multi-write (M) indicates that multiple virtual machines may issue 
writes concurrently to the disk. Generally, this mode of access 
requires that the virtual machines include code to control this, such as 
the shared DASD support of OS. See the description of the CP LINK 
command in the VM/370; Command Language Guide for General Users for more 
information about linking to minidisks. 
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Configurations 



Before you begin the system generation procedure, make sure your 
installation has the minimum configuration supported by VM/370 and the 
features and facilities required by VM/370. 



VMZ370 MINIMUM CONFIGUBATIOH 

The minimum configuration supported by VM/370 is: 

One CPU (245,760 bytes of storage) 

One system Console device 

One Printer 

One Card Reader 

One Card Punch 

Two Spindles of Direct Access Storage 

One Nine-Track Magnetic Tape Unit 

One Multiplexer Channel 

One Selector or Block Multiplexer Channel 

To determine the amount of real storage and direct access storage 
necessary for a configuration, see "Estimating VM/370 Storage 
Requirements." 

A representative VM/370 configuration is: 

IBM 3145 512K Storage 

IBM 3215 Console Printer-Keyboard 

IBM 1403 Printer, Model N1 — Two 

IBM 3330 Model 1 Disk Storage or 3333 Model 1 Disk Storage and 
Control — Four Drives attached to a 3830 Model 2 

IBM 2305 Fixed Head Storage Facility, Model 2 

IBM 3420 Magnetic Tape Units — Two 

IBM 2540 Card Read Punch 

IBM 3705 Communications Controller 

IBM 2741 Communication Terminals or IBM 3767 Communication 
Terminals, operating as 2741s (as needed) 

IBM 3277 Display Stations (as needed) with the 3272 Control Unit 
I (local attachment) or with the 3271 Control Unit (remote 

I attachment) 

I IBM 3275 Display Stations (as needed for remote attachment) 

Block Multiplexer Channels (#1421-1422) with Word Buffer 
feature (#8810) — Two 

Multiplexer Channel — One 
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CONFIGORATIONS SUPPORTED BY CMS 

CMS supports the following configurations: 

• Virtual storage size: minimum of 320K bytes, up to 16 million bytes 
in multiples of 4K. 

• Virtual console: any terminal supported by VM/370 as a virtual 
machine operator's console. 

• Any virtual card readers, punches, and printers supported by VH/370 
as spooling devices, except the 2520 Punch. 

I • Up to ten logical 2314, 2319, 3340, 3330 Model 1, 2, or 11, or 3333 
Model 1 or 1 1 direct access storage devices. The maximum size of a 
CMS minidisk is: 

— 246 cylinders, for a 3330 Model 1, 2, or 11 

— 246 cylinders for a 3333 Model 1 or 11 
I — 349 cylinders for a 3348 Data Module, Model 35 
I — 682 cylinders for a 3348 Data Module, Model 70 

— 203 cylinders (the entire disk) for a 2314/2319 

• Up to four 2400, 2415, 2420, 3410 (9 track only), or 3420 (7 or 9 
track) Magnetic Tape Units. 



I CONFIGORATIOHS SUPPORTED BY RSCS 



RSCS supports the following configurations: 

• Virtual storage size: Minimum of 512K, up to 16 million bytes in 
multi'^les of 4K« 

• Virtual console: any terminal supported by VM/370 as a virtual 
machine operator's console. 

• Any virtual card readers, punches, and printers supported by VM/370 
as spooling devices. 

• One logical 2314, 2319, 3330 Model 1, 2, or 11, 3333 Model 1 or 11, 
or 3340 direct access storage devices. 

• Transmission Control Units: 2701 Data Adapter Unit; 2703 Transmission 
Control Unit; or 3704 or 3705 Communications Controllers in EP mode 
only. Only binary synchronous communication transmission is 
supported. 

The minimum configuration supported by RSCS is: 

• 512K Virtual storage 

• One console 

• One Reader 
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I • One Transnission Control Unit 

I • One or nore binary synchronous lines dedicated to the RSCS virtual 
I machine 



DEVICES SUPPORTED BY Vj!^370 

The following devices are supported by VB/370 except as otherwise 
noted. The devices are listed by device type: 

• CPUs 

• Direct Access Storage Devices 

• Magnetic Tapes 

• Unit Record Devices (Printers, Readers, and Punches) 

• Terminals 

• Transmission Control Units 

• Remote Spooling Devices 

• Other Devices 
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CPUS 

VM/370 supports the following CPUs: 

IBM System/370 Model 135 

IBM System/370 Model 145 

IBM System/370 Model 155 II 

IBM System/370 Model 158 

IBM System/370 Model 158MP (uniprocessor mode) 

IBM System/370 Model 165 II 

IBM System/370 Model 168 

IBM System/370 Model 168MP (uniprocessor mode) 

All System/370 models must have at least 245,760 bytes of real main 
storage. 



CPU REQUIRED FEATURES AND FACILITIES 

VM/370 reguires the following CPU features and facilities: 

I • The System Timing facility (#2001) , which includes the clock 
comparator and the CPU timer, on the Models 135 and 145. 

• The Floating-point feature 

— For the Model 135, feature #3900 
— For the Model 145, feature #3910 

• The Channel Indirect Data Addresssing feature on each of the 2860, 
2870, and 2880 standalone I/O channels on the Model 165 II or 168. 

I —For the 2860, features #1861, 1862, and 1863 

I —For the 2870, feature #1861 

I — For the 2880, features #1861 and 1862 

Note: The standalone channels that attach to the System/370 Models 
I 165 II and 168 require that the Channel Indirect Data Addressing 
feature be ordered as a separate feature for proper operation of the 
input/output channels in a Dynamic Address Translation environment. 

I • The Word Buffer feature (#8810) , available only with the System/370 
I Model 145, is required if 

I — A 2305 Model 2 Fixed Head Storage device is attached. 

I — A 3340 Direct Access Storage Facility is attached. 

I — A 3330 configuration includes an Integrated File Adapter and two 
I Selector channels, or three or more Selector channels. 



DESIRABLE FEATURES 

The following CPU features are desirable for VM/370: 

• The Virtual Machine Assist feature improves the performance of VM/370 
systems that run virtual storage operating systems in virtual 
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machines. It is available as a hardware feature (fST^O) on the 
SysteiD/370 Models 135, 145, and 158, and as an RPQ (#520573) on the 
System/370 Model 168. 

• The Extended Floating-point feature, although not required, improves 
the execution of programs that use Extended Floating-point 
instructions under VM/370 on Models 135, 155 II, and 158. 

— For the Model 135, feature #3840 
— For the Model 155 II, feature #3700 
--For the Model 158, feature #3700 

• The Word Buffer feature (#8810) , available only with the System/370 
Model 145, is recommended for selector channels if the 2314, 3330, or 
3333 devices are attached. 
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DIRECT ACCESS STORAGE DEVICES 



The following direct access storage devices and control units are 
supported by vm/370. 

The direct access storage devices supported by VM/370 are: 

IBM 2305 Fixed Head Storage, Model 1 (Models 168 and 165 II only) 

IBM 2305 Fixed Head Storage, Model 2 

IBM 2314 Direct Access Storage Facility 

IBM 2319 Disk Storage 

IBM 3330 Disk Storage Models 1 2 and 1 1 

IBM 3333 Disk Storage and Control, Models 1 and 11 

IBM 3340 Direct Access Storage Facility, Models A2, B1, and B2; and 
I the 3348 Data Modules, Models 35, 70, and 70F. 

All of these direct access devices are supported as VM/370 system 
residence, paging and spooling devices. All except the 2305 are 
supported by CMS. 

The following direct access control units are supported by VM/370: 

• IBM 3345 Integrated Storage Control Models 3, 4, and 5 on the Model 
145 for: 

I —3330 Models 1 and 2 
I --3333 Models 1 and 11 
I —3340 Model A2 

• IBM 2835 Storage Control Model 1 for 2305 Model 1 (Models 165 II and 
168 only) 

• IBM 2835 Storage Control Model 2 for 2305 Model 2 

• IBM 2844 Auxiliary Storage Control for 2314 and 2319 

• IBM 3830 Storage Control Model 1 for 3330 Models 1 and 2 only 

I • IBM 3830 Storage Control Model 2 for 3333 Models 1 and 11, and 3340 
I Model A2 

• IBM Integrated File Adapter (#4650) on System/370 Models 135 and 145 
for 2319 

• IBM Integrated File Adapter (#4655) on the System/370 Model 135 for: 

I --3330 Models 1 and 2 
I —3333 Models 1 and 11 
I — 3340 Model A2 

• IBM Integrated Storage Control on the System/370 Model 158 for: 

I — 3330 Models 1 and 2 
I —3333 Models 1 and 11 
I —3340 Model A2 
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• IBM Integrated Storage Control on the System/370 Model 168: 

I — 3330 Models 1 and 2 
I — 3333 Models 1 and 11 
I — 33U0 Model A2 

• IBM 3333 Disk Storage and Control Models 1 and 11 for the 3330 Models 
1, 2, and 11 

I • IBM 33U0 Disk Storage and Control, Model A2 

No t es : 
1. The IBM 3330 Model 11 can be used as a system generation device in 
the same way as the 3330 Models 1 and 2, since the starter system 
does not use cylinders 404-807. 
I 2. A System/370 Model 145 must have the Word Buffer feature (#8810) 
I installed in order to attach a 3340 or 2305 Model 2. 
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MAGNETIC TAPES 



The following magnetic tape devices and control units are supported by 
vn/370. 

The magnetic tape devices supported are: 

• IBM 2401, 2402, and 2403 Magnetic Tape Units 

• IBM 2415 Magnetic Tape Units, Models 1, 2, 3, 4, 5, and 6 

• IBM 2420 Magnetic Tape Units, Models 5 and 7 

• IBM 3410/3411 Magnetic Tape Unit, Models 1, 2, and 3 {9-track only) 

• IBM 3411 Magnetic Tape Unit and Control, Models 1, 2, and 3 (9-track 
only) 

• IBM 3420 Magnetic Tape Units, Models 3, 4, 5, 6, 7, and 8 
The magnetic tape control units supported are: 

• IBM 2803 Tape Control 

• IBM 2804 Tape Control 

• IBM 3411 Magnetic Tape Unit and Control 

• IBM 3803 Tape Control 
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UNIT RECORD DEVICES 

VM/370 supports the following printers, readers, punches, and unit 
record control units. 

VM/370 supports the following printers: 

• IBB 1403 Printer Models 2, 3, 7, and N1 (with ninimum of 132 print 
positions) 

• IBM 1143 Printer Model Hi (with 144 print positions) 

• IBM 3211 Printer (Right Indexing only) 

• IBM 3213 Printer (in 3215 Emulator Mode) 
VM/370 supports the following readers/punches: 

• IBM 2501 Card Reader Models B1 and B2 

• IBM 2520 Punch Models B2 and B3 

• IBM 2540 Card Read Punch Model 1 

• IBM 3505 Card Reader Models B1 and B2 

• IBM 3525 Card Punch Models PI, P2, and P3 



VM/370 supports the following unit record control units: 

IBM 2821 Control Unit 

IBM 3811 Printer Control Unit 

IBM Integrated Printer Adapter (IPA) (#4662, 4667, or 4668) on the 

System/370 Model 135 
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TERMINALS 



The following system consoles are supported by VM/370 as virtual system 
consoles (simulated as 3215 consoles) , 

• IBM 2150 Console with 1052 Printer-Keyboard Model 7 

• IBM 3066 System Consoles Models 1 and 2 for the System/370 Models 165 
II and 168 

• IBM 3210 Console Printer-Keyboard Models 1 and 2 

• IBM 3215 Console Printer-Keyboard Model 1 

• IBM System Console for the System/370 Model 158 (in printer-keyboard 
mode with the 3213 Printer Model 1 required, or in display mode) 

• IBM 7412 Console (via RPQ AA2846) with 3215 Console Printer-Keyboard 
Model 1 

Note: During system generation only, the primary system operator's 
console cannot be connected to the system via a teleprocessing line. 

The following terminals are supported by VM/370 as virtual system 
consoles (simulated as 3215 consoles) : 

• IBM 2741 Communication Terminal 

• IBM 1050 Data Communication System 

• Terminals on switched lines compatible with the line control used by 
the IBM Telegraph Control Type II Adapter (8-level ASCII code at 110 
bps) such as the CPT-THX (Model 33/35) terminals 

• IBM 3275 Display Station, Model 2 with integral control unit (remote 
attachment only) 

• IBM 3277 Display Station, Model 2, via 3272 Control Unit, Model 2 
(local attachment only) 

• IBM 3277 Display Station, Model 2, via 3271 Control Unit, Model 2 
(remote attachment only) 

• IBM 3767 Communications Terminal, Model 1 (operating as a 2741) 



SPECIAL CONSIDERATIONS AND REQUIRED FEATURES 

Terminals that are equivalent to those explicitly supported may also 
function satisfactorily. You are responsible for establishing 
equivalency. IBM assumes no responsibility for the impact that any 
changes to the IBM-supplied programs or products may have on such 
terminals. 

Prior availability of an RPQ does not guarantee or imply current or 
future availability. Contact your IBM branch office for ordering 
information concerning the RPQs mentioned with the following features. 
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27^1 Z§§.tunes: Su££orted, Required, and Desirable Features 

The IBM 27U1 Comiunication Terminal is supported on either a switched or 
point-to-point nonswitched lines with these features: 

• PTTC/EBCD (#9571, Part #1167963) or standard Correspondence (#9812, 
Part #1167043) print elements 

• Transmit Interrupt (#7900) or Transmit Interrupt Control RPQ #E40681 

• Receive Interrupt (#4708) 

• For switched lines, the Data Set Attachment (#9114) and Dialup 
feature (#3255) are required 

• For point-to-point nonswitched lines, one of the following features 
is required: 

— Data Set Attachment (#9115 for facility D1), or 

— Data Set Attachment (#9116 for facility B2) , or 

— Data Set Attachment (#9120 for facility B1 or Dl), or 

— IBM Line Adapter (#4635 for 4-wire limited distance line) , or 

— IBM Line Adapter (#4691-4694 for 4-wire shared nonswitched line) 

— or — 

--IBM Line Adapter (#4647 for 4-wire nonswitched line) 

The following features, although not required, enhance the 
convenience and usability of the terminal: 

• Print Inhibit (#5501) 

I • Red Ribbon Control RPQ #868019 (supported for PTTC/EBCD keyboard 

I only) 

• Typamatic Keys (#8341) 

• Pin Feed Platen (#9509) 



1050 Control Units, Models, and Features: Su££orted, Required, and 
l§sirable Features 

The IBM 1050 Data Communication System is supported on either switched 
or point-to-point nonswitched lines with these features: 

• IBM 1051 Control Unit (Model 1 or 2) with these features: 

— Transmit Interrupt (#7900) or Transmit Interrupt Control RPQ 
#E26903 

— Receive Interrupt (#6100) or Receive Interrupt Control RPQ #27428 

— Text Time-Out Suppression (#9698) 

— First Printer Attachment (#4408) . This feature is required to 
attach a 1052 Printer-Keyboard to the 105 1 

• IBM 1052 Printer-Keyboard (Model 1 or 2) with the PTTC/EBCD print 
element (#9571, Part #1167963) 

• For switched lines, the Data Set Attachment (#9114) is required 
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• For point-to-point nonswitched lines, one of the following is 
reguired : 

— Data Set Attachment (#9115 for facility D 1) 

— or — 
— Data Set Attachment (#9116 for facility B2) 

— or — 
— Data Set Attachment (#9120 for facility B1 or D1) 

— or — 
— IBM Line Adapter (#1691-4694 for 4-wire shared nonswitched line) 

— or — 

— IBM Line Adapter (#4647 for 4-wire nonswitched line) 

The following features, although not reguired, enhance the 
convenience and usability of the terminal: 

• Automatic Ribbon Shift and Line Feed Select (#1295) 

• Automatic BOB on Carrier Return RPQ #E 28235 



I 3270 Components, Control Units, Models, and Features: Suf ported, 
5e2S.i£®^, and Desirable Features 

The IBM 3270 Information Display System is supported on a byte 
multiplexer, block multiplexer or selector channel with these 
components: 

• IBM 3271 Control Unit, Model 2, for remote attachment of 3277 display 
stations 

• IBM 3272 Control Unit, Model 2, for local attachment of 3277 display 
stations 

• IBM 3275 Display Station, Model 2 (remote attachment) , or 
IBM 3277 Display Station, Model 2 (local or remote attachment) , with 
one of the following features reguired: 

— 66 Key EBCDIC Typewriter Keyboard (#4630) 
—66 Key EBCDIC Data Entry Keyboard (#4631) 
— 78 Key Operator Console - Keyboard (#4632) 
—78 Key EBCDIC Typewriter Keyboard (#4633) 

The following features, while not reguired, enhance the convenience 
and usability of this terminal: 

— Keyboard Numeric Lock (#4690) 

— Audible Alarm (#1090) 

— Operator Identification Card Reader (#4600) 

— Lower Case Character Display (RPQ #8K0366) 

Note: Unless a 3270 terminal is dedicated to a virtual machine, it is 
supported only as a virtual 3215; that is, it is not supported by 
VM/370 as a real local or remote 3270. 
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I • IBM 3284 Printer, Models 2 and 3 (for remotely attached 3270s) 

I • IBM 3286 Printer, Models 2 and 3 (for remotely attached 3270s). The 
I Model 3 attaches to the 3275 display station only if RPQ MBU317 is 
I installed. 

I • IBM 3288 Line Printer, Model 2 (for remotely attached 3270s) 



3767 Features: Beguired and Desirable Features 

The IBM 3767 Communication Terminal, Model 1, is supported when it 
operates as an IBM 27U1 Communication Terminal and is attached to a 3704 
or 3705 Communications Controller. It requires the following features on 
either switched or nonswitched point-to-point lines: 

• 2741 START/STOP (#7113) 

• EBCDIC (#9391) or Correspondence (#9381) keyboard 

• Half -duplexed, switched or nonswitched line (#9402) 

• One of the following: 

— EIA Interface with Clock (#3719) at 300 bps 

— 1200 bps Integrated Modem/Interrupt (#5505 or #5500) 

The following features, although not required, enhance the 
convenience and usability of the terminal: 

• Alternate Character Set (#1291) , plus a defined character subset for 
the keyboard: 

— If the primary character set is Correspondence (#9381) , the 
alternate character set can be APL (#9383) or EBCDIC (#9382) . 

— If the primary character set is EBCDIC (#9391) , the alternate 
character set can be APL (#9393) or Correspondence (#9392) . 

Note: Line control is PTTC/EBCD with this feature. 

• Acoustic Coupler (#1110) at 300 bps #9540 
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TRANSMISSION CONTROL UNITS 

VB/370 supports the following transmission control units: 

• IBM 2701 Data Adapter Unit 

• IBM 2702 Transmission Control 

• IBM 2703 Transmission Control 

• IBM Integrated Communications Attachment (ICA) , (#4640) 

• IBM 3704 and 3705 Communications Controllers 

2701 REQUIRED FEATURES 

• For line control of CPT-TWX (Model 33/35) terminals, the Telegraph 
Adapter Type II (#7885) is required. / 

• For 2770, 2780, 3770 (as a 2770), and 3780 terminals, the following 
are required: 

— Synchronous Data Adapter Type II (#7698) 

— EBCDIC code (#9060) 

— EBCDIC transparency (#8029) 

• For 1050 and 2741 terminals, the following are required: 
—IBM Terminal Adapter Type I, Model II (#4640) 
--Selective Speed, 134.5 bps (#9581) 

--2741 Break Feature RPQ #M53193, and Break Command RPQ #858492 

• The Expanded Capability feature (#3815) is required if there are: 

— More than two low speed adapters (either IBM Type I Model II, or 
Telegraph Type II) , or 

— More than one high speed adapter (Synchronous Data Adapter Type 
II) r or 

— One high speed and at least one low speed adapter attached to the 
same 2701. 

• The Expansion Feature (#3855) is required for each line adapter after 
the first. 

2702 REQUIRED AND OPTIONAL FEATURES 

• For 1050 and 2741 terminals, the following are required: 
— Terminal Control Base for IBM Terminal Control (#9 696) 
— IBM Terminal Control Type I (#4615) 

— Selective Speed, 134.5 bps (#9684) 
— Type I Terminal Interrupt (#8200) 
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— Data Set Line Adapter (#3233) or IBM Line Adapter (#4635) , 4-wire 
IBM Terainal Control Type I (#4615) 

• For line control of CPT-TWX (Model 33/35) terainals, the following 
are required: 

— Terninal Control Base for Telegraph Terminal Control (#9697) 

— Telegraph Terminal Control Type II (#7912) 

— Pluggable End Characters (return key generates an interrupt) RPQ 
#E62920, optional 

— Data Set Line Adapter (#3233) 

— Terminal Control Expansion (7935) , required only if both of the 
terminal bases (#9697 and #7912) are attached to the same 2702. 

• The 31 Line Expansion (#7955) is supported as needed. 
2703 REQUIRED AHD OPTIONAL FEATURES 

• For 1050 and 27U1 terminals, the following are required: 
— Start-Stop Base Type I (#7505) or Type II (#7 506) 

— IBM Terminal Control Base (#4619) 

— IBM Terminal Control Type I (#4696) 

— Line Speed Option, 134.5 bps (#4878) 

— Type I Terminal Interrupt (#8200) 

--Data Line Set (#3205) and/or IBM Line Set IB (#4687) 

• For line control of CPT-TIX (Model 33/35) terminals, the following 
are required: 

— Telegraph Terminal Control Base (#7905) 

— Telegraph Terminal Control Type II (#7912) 

— Line Speed Option, 110 bps (#4877) 

— Data Line Set (#3205) , and Data Line Set Expander (#3206) 

— Pluggable End Characters (return key generates an interrupt) RPQ 
#E66707, optional 

I • For 2770, 2780, and 3780 Terminals, the following are required: 

— Synchronous Base (#7703, 7704, or 7706) 

— Synchronous Terminal Control for EBCDIC (#7715) 

— Transparency (#9100) 

— Synchronous Line Set (#7710) 

• The Base Expansion feature (#1440) is required if more than one base 
type is to be attached to the same 2703. 
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IBM INTEGRATED COMMUNICATIONS ATTACHMENT (ICA) REQUIRED AND OPTIONAL 
FEATURES 

The ICA '#^6^0^ is available on the S^stei5'37Q Model 135. Additional 
lines (#4722-4728) are supported. 

I • For 1050, 2741, and 3767 (as a 2741) terminals, the following are 
reguired : 

--Terminal Adapter Type I Model II (#9721-9728) 

— Switched Network Facility (#9625-9632) , optional 

— Write Interrupt (#9745-9752) 

— Unit Exception Suppression (#9729-9730) , optional 

I —For the 3767 only, as a 2741, 200 bps (#2711-2718) or 300 bps 
I (#9593-9600) 

I • For 2770, 2780, 3770 (as a 2770) and 3780 terminals, the following 
I are reguired: 

— Synchronous Data Adapter Type II (#9649-9656) 

--Half Duplex Facility (#9617-9624) 

— EBCDIC Transparency (#9673-9680) 

• For line control of CPT-TWX (Model 33/35) terminals, the following 
are reguired: 

— Telegraph Adapter Type II (#9785-9792) 

— Switched Network Facility (#9625-9632) 



3704/3705 REQUIRED FEATURES 

The IBM 3704 and 3705 Communications Controllers are supported in 
Network Control Program mode. Partitioned Emulation Program mode, and 
2701, 2702, 2703 Emulation Program mode. 

Note: VM/370 supports the CPT-TWX (Model 33/35) terminals only at 110 
bps when when attached to a 3704 or 3705. 

VM/370 supports all models of the 3704 and 3705 Communications 
Controllers. However, because the network control program and 
partitioned emulation program reguire 48K of storage, the following 
models are supported for the emulation program only. 

• IBM 3704 Communications Controller Models A1 and A2 

• IBM 3705 Communications Controller Models Al, B1, CI, and D1 

The features reguired on a communications controller do not depend on 
VM/370. VM/370, when supporting network control mode, reguires a 
communications controller with at least 48K of storage. Other 3704/3705 
features depend upon the intended use of the communications controller 
and the type of 3704/3705 control program (emulation, network control or 
partitioned emulation program) to be executed. 
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I VM/370 does not support the following 3704/3705 features 

I • Line Set Type 2A (#U721) 

I • Line Set Type 3A (#4731) 

I • Line Set Type UB (#4742) 
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REMOTE SPOOLING DEVICES SUPPORTED BY VM/370 

Remote spooling is supported in VM/370 by the 2780 standalone program 
(DMKSRP) and the Remote Spooling Communications Subsystem (RSCS) . 



VH/370 supports the IBM 2780 Data Transmission Terminal Model 2, for 
standalone remote spooling (the DMKSRP Spool Remote Program) , with these 
features: 

• EBCDIC Transmission Code (#9762) 

• EBCDIC Transparency (#8030) 

• 144 Character Print Line (#5820, 5821) 

• Automatic Turnaround (#1350) , if the 2780 is using a switched line 
facility 



REMOTE SPOOLING COMMUNICATIONS SUBSYSTEM (RSCS) 

The VM/370 Remote Spooling Communications Subsystem (RSCS) supports the 
following: 

• IBM 2770 Data Communication Terminal 

• IBM 2780 Data Transmission Terminal, Models 1 and 2 

• IBM 3770 Data Communication System (as a 2770) 

• IBM 3780 Data Communication Terminal 

• HASP supported programmable workstations 



2220 Features: Reguired and Optional Features 

The IBM 2770 Data Communication System with the 2772 Multipurpose 
Control Unit can be connected to the central System/370 via a switched 
or nonswitched point-to-point communication line. 

The following devices and features are reguired for operating a 2770 
as an NPT remote station: 

• One IBM 2213 Printer, Model 2, or one IBM 2203 Printer, or one IBM 
1503 Printer 

• One IBM 2502 Card Reader, Model Al or A2 

• EBCDIC Transmission Code (#9761) 

Other supported eguipment and features are: 

• One IBM 545 Card Punch, Model 3 or 4, with or without 3590 attachment 

• EBCDIC Transparency (#3650) 

• Additional Buffer Expansion (#1491) 

• Space Compression/Expansion (#6555) 

• synchronous Clock (#7705) 
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22M l6§t!iE§§* 5S3Mi£®d and Optional Features 

The IBM 2780 Data Transiission Terainal, Models 1 and 2, can be 
connected to the central SysteB/370 via a switched or nonswitched 
point-to-point line. EBCDIC Transiission code (#9762) is required. 

The following features are optional: 

• EBCDIC Transparency (#8030) 

• 120/144 Character Print Line (#5820 or #5821) 

• Multiple Record Transiission (#5010) 

• Synchronous Clock (#7705) 



3770 Features 

The IBM 3770 Data Comiunication System can be connected to the central 
Systea/370 via a switched or nonswitched point-to-point conmunications 
I line. Required features are: 

• EBCDIC Transiission Code (#9761) 

• SDLC/BSC Switch Control (#1460) 

• BSC point-to-point (#1461) 



1280 l6^tli£6s: Required and Optional Features 

The IBM 3780 Data Coimunications Terminal can be connected to the 
central System/370 via a switched or nonswitched point-to-point 
communications line. EBCDIC transmission code (#9761) is required. 

The following devices and features are optional: 

• One IBM 3781 Card Punch 

• Component Selection (#1601, required for the 3781) 

• EBCDIC Transparency (#3601) 

• Additional Print Positions (#5701) 

• Synchronous Clock (#7705) 



Eg.2g£§Si§^J:§ Term in a.ls 

RSCS Spool MULTI-LEAVING* (SML) supports, as a VM/370 remote 
workstation, any processor that is supported as a HASP workstation and 
is programmed to operate as a HASP workstation. 



*IBM Unregistered Trademark 
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I CPUs Su££orted 



• The IBM 1130 Computing System (except Hodels hA and hB) is supported 
if it has at least 8K words of storage and the Synchronous 
Communications Adapter (#7690) . 

• Any System/360 or System/370 is supported if it has at least 8K bytes 
of main storage and a 2701, 2703 or 3704/3705 in EP mode, equipped 
for EBCDIC transmission and binary synchronous communications c 

• Any submodel of the System/360 Model 20 or the IBM 2922 is supported 
if it has at least 8K bytes of main storage and the following 
features: 

— Binary Synchronous Communications Adapter (#2074) 

— EBCDIC Transmission code (#9060) 

— Full Transparency (#4100) 

• IBM System/3 is supported with the following features: 
— Binary Synchronous Communications Adapter (#2074) 

— EBCDIC Transmission code (#9060) 
— Text transparency (#7850) 
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OTHER CONSIDERATIONS FOR PLANNING YOUR CONFIGURATION 



THO-CHANNEL SWITCH 

VM/370 has no multiple path support and does not take advantage of the 
two-channel switch. However, a two-channel switch can be used between 
the System/370 running a virtual machine under VM/370 and another CPU. 

I If any I/O devices controlled by VM/370 for its exclusive use are 
I attached to control units with two-channel switches, the CPU or virtual 
I machine controlling the other channel interface must vary the CP-owned 
I devices offline. 

I See the "VM/370 Using Channel Switching" section earlier in Part 1 
I for more information about using the two-channel switch. 



DEVICES USED ONLY BY AN OPERATING SYSTEM IN A VIRTUAL MACHINE AND NOT BY 
VM/370 

Any input/output device that can be attached to the IBM System/370 can 
be used by a virtual machine under VM/370 as long as there are: 

• No timing dependencies in the device or the program 

• No dynamically modified channel programs except OS Indexed Sequential 
Access Method (ISAM) or OS/VS Telecommunications Access Method (TCAM) 
Level 5 

• None of the other restrictions outlined in the VM/370: Introduction 
are violated. 

Dynamically modified channel programs (except those that have 
input/output involving page zero) are permitted if run in a virtual=real 
machine. 

Input/output devices that are part of a virtual machine's 
configuration require real device equivalents, except for: 

• Unit record devices, which CP can simulate using spooling 
techniques. 

• Virtual 2311 Disk Storage Drives, which CP can map onto 2314 or 2319 
disks. Up to two full 2311 units can be mapped onto a 2314 or 2319 
disk in this manner. 
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Part 2: Defining Your VM/370 System 



I Part 2 describes the macros and control statements you need to define 

I your VM/370 system. It contains the following sections: 

! • Preparing the Real I/O Configuration File (DMKRIO) 

I • Preparing the CP Control File (DMKSYS) 

! • Creating Your VM/370 Directory 

I • Preparing the system Name Table File (DHKSNT) 

I • Altering the Forms Control Buffer Load (DHKFCB) 
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Before starting the system generation procedures on a real machine, you 
must create three files that describe the VM/370 system you are 
g@n@ratj.nga There are two aduXi,xcnaj. ^Xj.es, WuXCu are optxcnaj.. You can 
use card input, or create these files using the CMS Editor. If you are 
modifying an existing VM/370 system, you can use the CMS Editor to alter 
the existing files. 

The three files that you must prepare are: 

• The real I/O configuration file (module name DMKRIO) , which defines 
the I/O configuration on the real System/370 machine. 

• The CP system control file (module name DMKSYS) , which defines 
CP-controlled DASD volumes, allocation, and so on. 

• The VM/370 directory file (normally a CMS file named USER DIRECT) , 
which contains the VM/370 directory entries that define the virtual 
machine configuration for each user. 

In addition, you should prepare the system name table (DMKSNT) file 
if you plan to save systems. If you generate the 3704/3705 control 
program, you must save it; otherwise, the 3704/3705 control program 
cannot be loaded by VM/370. "Part 1: Planning for System Generation" has 
a section that describes the reguirements for saving systems. 

You can also change the forms control buffer load (module name 
DMKFCB) . 

The notational conventions that describe the macro syntax for VM/370 

system generation are listed in "Appendix E. Notational Conventions." 

These notational conventions are the same as the conventions used to 
describe VM/370 commands. 
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I All the groups of CLUSTER and TERMINAL macros must appear first, 

\ followed b^ all RDEVICE macros, all RCTLUNIT macros all RCHANHEL 

macros, and finally by the RIOGEN macro. In addition, the first 

statement in the file must be the DMKRIO CSECT statement (as shown) and 

the last statement must be the assembler END statement. 



i S3^i^^ iiJi £2AL I/O CONFIGURATION MACROS FOR REMOTE J^_/uS 

I Two types of remote 3270 configurations are supported: a clustered 3271 
! station with multiple terminals and printers attached and a standalone 

3275 station. These remote 3270 stations are attached via binary 

sysnchronous communications lines. 

To define remote 3270 stations you must code CLUSTER, TERMINAL, and 
RDEVICE macros. Code one RDEVICE macro for each binary synchronous line 
that supports a remote 3270 configuration. Code one CLUSTER macro to 
define the 3270 control unit for each of those lines and code one or 
more TERMINAL macros, as needed, to define the devices in the remote 
3270 configuration. 

Code one CLUSTER macro for each binary synchronous line used by 
remote 3270s. The CLUSTER macro defines the control unit (3271 or 3275) 
for the remote 3270 configuration. Each CLUSTER macro must have a 
unique label. This label is coded on the RDEVICE macro that defines the 
corresponding binary synchronous line and thus logically links the line 
and the cluster. The address of the line (defined by the ADDRESS=cuu 
operand of the RDEVICE macro) is coded in the LINE=cuu operand of the 
CLUSTER macro. 

Follow each CLUSTER macro with the TERMINAL macros that define the 
terminals for the remote 3270 control unit. For the 3271, directly 
following the CLUSTER macro, code a TERMINAL macro for each terminal 
address to which a terminal can be attached (regardless of whether or 
not the intermediate addresses are unused) . For example, if terminals 
are attached to the third, fourth, eighth, and ninth addresses, you code 
nine TERMINAL macros. The first macro represents the first (lowest) 
address- the last re'^resents the ninth (highest) address. 

For the 3275, directly following the CLUSTER macro, code a single 
TERMINAL macro specifying TERM=3275. If the 3275 has a 3284 or 3286 
Model 3 Printer attached, specify M0DEL=3 to define the printer; 
otherwise, the printer is ignored. 

After all the CLUSTER-TERMINAL groups of macros have been coded, code 
the other real I/O configuration macros. You must code an RDEVICE macro 
for each binary synchronous line that supports remote 3270 stations. 
Specify the label of the corresponding CLUSTER macro on the RDEVICE 
macro (CLUSTER=label) . 
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I CLDSTER MACRO 

I Use the CLUSTEB aacro to define remote 3270s. Each CLUSTEB macro 

I represents a clustered (3271) or standalone (3275) station on a 

I nonswitched point-to-point binary synchronous comnunication line. Only 
I one CLUSTER macro can be specified for each communication line. 

I The format of the CLUSTEB macro is: 

I , — • 1 

I {Name | Operation | Operands 
I 



labell CLUSTEB | CUTYPE=/327 1 ) 

III I 13275/ 

III I ,GPOLL=cudv 

I I ,LINE=cuu 



I wher e : 

I label 

I is a name of the CLUSTER macro; it must be specified. The label 

I may be any valid assembler language symbol. The label establishes 

I a unique symbolic name for this cluster or standalone station. 

I CUTYPE=/3271 \ 

I 13275 j 

I is the control unit of the station; it is either 3271 or 3275. 

I GPOLL=cudv 

I are the general polling characters that represent the general 

I polling technique to be used for this station. When general 

I polling is used, the first device that the control unit determines 

I is ready to send data over the line is allowed to do so. The 

I characters, cudv, are the four-digit hexadecimal general polling 

I characters assigned to the control unit of the station. The 

I hexadecimal equivalent of the EBCDIC transmission code in in the 

! form cudv, where: 

I cu are the polling characters for the control unit. 

I dv are the characters for any available input device (normally 

I X'7F') 

I The general polling characters for the remote 3270 device (dv) are 

I always X'7F' and the general polling characters for the control 

I unit are defined when the control unit is physically installed. 

I Use Figure 15.1 to determine what you should code as the general 

I polling characters for the control unit. 

I LINE=cuu 

I is the line interface address. It is the address specified on the 

I RDEVICE macro that is associated with this CLUSTER macro. 



I Examples 

I The following CLUSTER macro describes a 3271 control unit with a control 

I unit address of 2 and a line address of 078. 

I CLUST001 CLUSTER CUTyPE=327 1, GPOLL=C27F,LINE = 078 
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CLUSTER Macro 

I The following CLUSTER macro describes a 3275 display station with a 
I control unit address of and a line address of 080. 

I CLUST020 CLUSTER CUTYPE=3275, GPOLL=407F,LINE=080 

I In the real I/O configuration file (DHKRIO) , the CLUSTER aacro must 
I immediately precede the TERMINAL macros that define the stations 
I attached to that cluster or standalone station. 



I MMOTE Messages 

} The following MNQTE messages may be generated by the CLUSTER macro 

I instructions. 

I INVALID CUTYPE OPERAND 

I indicates that the control unit is not specified correctly: 3271 

I and 3275 are the only valid operands. 

I CUTYPE NOT SPECIFIED 

I indicates that the required operand, CUTYPE=3271 or 3275, is 

I missing. 

I INVALID GPOLL OPERAND 

I indicates that the general polling characters are specified 

I incorrectly. See Figure 15.1 for the valid general polling 

I characters. 

I GPOLL NOT SPECIFIED 

I indicates that the required operand, GPOLL=cudv, is missing. 

I INVALID LINE OPERAND 

I indicates that one or more of the line addresses is specified 

I incorrectly. 

I LINE NOT SPECIFIED 

I indicates that the required operand, LINE=cuu, is missing. 

I NAME FIELD NOT SPECIFIED 

I indicates that the label field is not coded on one or more CLUSTER 

I macro. The name field, or label, must be specified on all CLUSTER 

I macros. 

I MORE THAN 16 LINES FOR REMOTE CLUSTERS 

I indicates that more than 16 CLUSTER macros are in the DMKRIO file: 

I 16 is the maximum allowed. 

I CLUSTER MACRO OUT OF SEQUENCE 

I indicates that a CLUSTER macro is out of sequence. Each CLUSTER 

I macro must immediately precede the TERMINAL macros defining the 

I devices attached at each remote 3270 station. The groups of 

I CLUSTER and TERMINAL macros must precede all other macros in the 

I DMKRIO file. 
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I TEMMAk MACRO 



Dse the TERMINAL aacro to define (1) a display station or printer that 
is attached to the remote 3270 display systen or (2) a terminal address 
that is available to attach an additional renote 3270. Each tersinal 
address attached to a cluster must be represented by a TERMINAL macro. 
Only one TERMINAL macro is specified for a standalone display station. 

Code one TERMINAL macro for each display device and each printer 
attached to a clustered control unit (3271) . You must code a TERMINAL 
macro for every terminal address to which a terminal can be attached, 
even if a terminal address is unused. When you code a TERMINAL macro 
for an unused terminal address, specify a valid TERM= operand and the 
correct selection or addressing characters. 

Code only one TERMINAL macro to define the display station, and 
optionally a printer, attached to a standalone station (3275) . Code 
TERM=3275 to define the 3275 display station and, optionally, code 
M0DEL=3 to define a 3284 or 3286 printer attached to the 3275. 



The format of the TERMINAL macro is: 



Name | Operation | Operands 



TERMINAL 



TERM= 3275 
3277 
328U 
3286 
3288 

,SELECT=cudv 

,M0DEL=2"I 
,M0DEL=3 J 

[ ,FEATDRE=OPRDR] 



w her e : 
TERM=| 3275 
3277 
3284 
'3286 
3288 
is the device type of 
clustered or standalone 
are allowed: 

Device 

IBM 3275 Display Station 

IBM 3277 Display Station 

IBM 3284 Printer 

IBM 3286 Printer 

IBM 3288 Line Printer 



the remote 3270 station attached to the 
3270 control unit. The following devices 



TERH = 

3275 

3277 

3284 

3286 

3288 



SELECT=cudv 

are the four-digit hexadecimal selection or addressing characters 
assigned to this device, where: 

cu are the characters for the control unit 
dv are the characters for the device 
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Use Figure 15.1 to determine the selection and addressing 
characters for this device. 

Note: If a printer is attached to the 3275, it has the same address 
as the 3275 display station. 



r MQDELf 2 1 
.=3 J 



lmodel= 



The following printers can be attached to a 3271 clustered control 
unit: 

• IBM 3284 Printer, Model 2 

• IBM 3286 Printer, Model 2 

• IBM 3288 Printer, Model 2 

The following printers can be attached to a standalone 3275 
station: 

• IBM 3284 Printer, Model 3 

• IBM 3286 Printer, Model 3 (via RPQ MB4317) 

FEATUBE=OPBDR 

specifies the optional feature, operator identification card 
reader, that is available on the 3277 Display Station, Model 2. 



I Examples 

Example 1.: This TERMINAL macro describes a 3277 with a selection address 
of 2, and a control unit address of 2. 

TERMINAL TERM=3277 ,SELECT=E2C2, FEATORE=OPRDR 

Example 2: This TERMINAL macro describes a 3286 with a selection address 
of 3 and a control unit address of 3. 

TERMINAL TERM=3286, SELECT=E3C3 

Example 3: This TERMINAL macro describes a 3284 with a selection address 
of 4 and a control unit address of 4. 

TERMINAL TERM=3284,SELBCT=E4C4,MODEL=2 

Example 4: This TERMINAL macro describes a 3275 Display Station with a 
3284 Printer, Model 3, attached and a control unit address of 0. 

TERMINAL TERM=3275,SELBCT=6040, M0DEL=3 

If no printer is attached to the 3275, code: 

TERMINAL TERM=3275, SELECT=6040 



Part 2: Defining Your VM/370 System 96.5 



GC20-1801-a, Page Modified by GN20-2658, March 31, 1975 
TERMINAL Macro 

I 15J0TE Messages 

The folloving MHOTE messages may be generated by the TERMINAL macro 
instructions. 

INVALID 'TERM* OPERAND 

indicates that the device type is not specified correctly; 3275, 
3277, 3284, 3286, and 3288 are the only valid operands. 

'TERM' NOT SPECIFIED 

indicates that the required operand, TERM=32xx, is missing. 

INVALID 'SELECT' OPERAND 

indicates that the selection or addressing characters are specified 
incorrectly. See Figure 15.1 for the valid selection or addressing 
characters. 

•SELECT' NOT SPECIFIED 

indicates that the required operand, SELECT=cudv, is missing. 

INVALID 'MODEL' NUMBER 

indicates that the model number is specified incorrectly; 2 and 3 
are the only valid model numbers. 

INVALID 'FEATURE' OPERAND 

indicates that the feature operand is specified incorrectly; OPRDR 
is the only valid feature. 

TERMINAL MACRO OUT OF SEQUENCE 

indicates that a TERMINAL macro is out of sequence. All the 
TERMINAL macros defining the devices attached to a remote 3270 
station must follow the CLUSTER macro that defines the control unit 
for that station. The groups of CLUSTER and TERMINAL macros must 
precede all other macros in the DMKRIO file. 
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1 Dse this column 


for? 




j Use th 


is column for: 




1 • Device selection 




1 • 3270 control unit selection 




1 • Specific poll 




1 add] 


cesses 




1 • General poll 












1 • Fixed return 


addresses 










1 If the Control 


The EBCDIC 




1 If the 


Control 1 The EBCDIC 




i Unit or Device 


Code (in 




i Unit B- 


iffiber is: j Cods (in 




1 Number is: | 


hexadecima 

is: 

See Note 1 


1) 




1 hexadecimal) 

1 is: 

1 See Note 1 




1 1 


UO 




1 


1 60 


1 


i 1 i 


CI 




i 1 


i 61 




1 2 1 


C2 




1 2 


1 E2 




1 3 1 


C3 




1 3 


1 E3 




1 ** 1 


C4 




1 >* 


1 £U 




1 5 1 


C5 




1 5 


1 E5 




i 6 1 


C6 




1 6 


1 E6 




1 7 1 


C7 




1 7 


1 E7 




1 8 1 


C8 




i 8 


1 E8 




1 9 1 


C9 




1 9 


1 E9 




1 10 1 


i4A 




1 10 


t 6A 




1 11 1 


4B 




1 11 


1 6B 




1 12 1 


4C 




1 12 


1 6C 




1 13 1 


UD 




1 13 


1 6D 




1 1'* 1 


4£ 




1 l'^ 


i 6E 




1 15 1 


4F 




1 15 


1 6F 




1 16 1 


50 




1 16 


1 FO 




I 17 1 


D1 




1 17 


1 F1 




1 18 1 


D2 




1 18 


1 F2 




1 19 1 


D3 




1 19 


1 F3 




1 20 1 


D4 




1 20 


1 F4 




1 21 1 


D5 




1 21 


1 F5 




1 22 1 


D6 




1 22 


1 F6 




1 23 t 


D7 




1 23 


1 F7 




i 24 1 


D8 




1 2a 


1 F8 




1 25 1 


D9 




1 25 


1 F9 




! 26 ! 


5A 




! 26 


1 7A 




1 27 1 


5B 




1 27 


1 7B 




1 28 1 


5C 




1 28 


1 7C 




1 29 1 


5D 




1 29 


1 7D 




1 30 1 


5E 




1 30 


1 7E 




1 31 t 


5F 




1 31 


1 7F 




1 M2^g_li Graphic 


characters 


for 


the United States I/O interface 




1 codes are shown. 


Graphic cl 


liaracters for 


EBCDIC 4A, 5A, 5B, 7B, 




1 7C, and 7F might 


differ for 


particular World Trade I/O interface 




1 codes. 













I Figure 15.1. Remote 3270 Control Unit and Device Addressing 
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I Figure 15.2 shows soae examples of valid polling characters. 



3271 Addressing 



3275 Addressing 



General Poll 
for Control 
Unit 5 


Control 

Unit 

Address 


EBCDIC 


■General Poll 
— Ifor Control 

(Unit 5 

1 
-1 

1 

1 


IControl 

lUnit 

1 Address 

1 
1 


EBCDIC 


C5 
C5 


C5 
C5 




Device 
Address 


7F 
7P 


1 

1 Device 

1 Address 


7F 
7F 


Specific 
Poll Device 
U on Control 
Dnit 5 


Control 

Unit 

Address 


C5 
C5 


ISpecific 

IPoll 

|for Control 

lUnit 5 
1 


IControl 

lUnit 

(Address 

1 
1 


C5 
C5 




Device 
Address 


cn 


1 
1 

1 


1 

1 Device 

lAddress 


UO 
40 


Select 
Device 4 
on Control 
Unit 5 


Control 

Unit 

Address 


E5 
E5 


1 Select 
1 Control 
IDnit 5 

1 
1 


IControl 

lUnit 

lAddress 

1 
1 


E5 
E5 




Device 
Address 


CU 
C4 


1 
1 
1 


1 

1 Device 
lAddress 


40 
40 



I Figure 15.2. Exaaples of Remote 3270 Addressing 
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Preparing the Real I/O Configuration File (DMKRIO) 



The real I/O configuration file consists of macros that describe the I/O 
devices, control units, and channels attached to the real Systea/370. 
VM/370 uses this inforaation to schedule I/O operations and to allocate 
resources. Therefore, the real I/O macro entries must represent the 
real hardware configuration accurately. Generally, there must be one 
real I/O macro entry for each hardware unit in your configuration. 

You can include entries for more devices than your installation has 
so that devices can be added in the future without performing another 
system generation, but bear in mind that the control blocks generated 
(RDEVBLOK, RCUBLOK, and BCHBLOK) occupy space in real storage. 

When preparing the RDEVICE and RCTLONIT entries, refer to "Appendix 
B: Configuration Aid" to assist you in configuring control units and 
devices. Following the descriptions of the CLUSTER, TERMINAL, RDEVICE, 
RCTLONIT, RCHANNEL, and RIOGEN macros, there is an example showing how 
these macros are coded for one particular real configuration. 

The macros, in their proper seguence, are: 

]?§cro_Name Units_Ref erred_To 
CLUSTER j Remote Display Stations 
TERMINAL 



RDEVICE 
RCTLUNIT 
RCHANNEL 
RIOGEN 



I/O Devices 
Control Units 
Channels 
System Console 



The file is placed in the reader as follows; 

DMKRIO CSECT 

CLUSTER macro! 
TERMINAL macro* 

RDEVICE macros 

RCTLUNIT macros 



RCHANNEL macros 



RIOGEN macro 
END 



*There must be a CLUSTER macro for each binary synchronous line for 
remote 3270s. Each CLUSTER macro must be followed immediately by the 
TERMINAL macros representing each display station and printer on that 
line. The CLUSTER and TERMINAL macro groups must precede all the other 
real I/O configuration macros. 



96 VM/370: Planning & System Generation Guide 



107^ 



RDEVICE Macro 



RDEVICE MACRO 



Use the RDEVICE macro instruction to generate a real device block 
(RDEVBLOK) . You Bust code an RDEVICE nacro for each real I/O device in 
your I/O configuration. The naxinum number of real devices that can be 
included on the real VM/370 system is 3276. 



RD 



TVD WTO 



S macro instructions describe each device- 



or arouD 



of 



devices, attached to the System/370. These can be in any order, but 
they must be contiguous, and must precede all RCTLONIT and RCHANNEL 
macros in the real I/O configuration file (DMKHIO) . Also, the RDEVICE 
macro instructions must follow all the groups of CLUSTER and TERMINAL 
macros, if there are any. The first RDEVICE macro generates the label 
DMKRIODV, which indicates the start of the real device blocks to CP. 

The name field may not be specified for the RDEVICE macro 
instruction; if a name is specified it is ignored. The RDEVICE macro 
generates a name by appending the device address to the characters RDV. 
For example, the name RDV234 is generated for the device address 231. 

Before you code an RDEVICE macro for a 3704 or 3705 device, see the 
"Generating a VM/370 System that Supports the 3704/3705" section of Part 
1 for additional information and special considerations. 

Also, see the "Planning Considerations for Remote 3270s" section of 
Part 1 before you code an RDEVICE macro for a binary synchronous line 
that is used by remote 3270s. 

The format of the RDEVICE macro is: 



Name | Operation | Operands 



RDEVICE 



ADDRESS=| 



,DEVTYPE=type[ ,MODEL=model ] 



■•(cxxn ^ 

I (cuu,nn) j 
[ ,FEATDRE= (f eature[ , feature]. . . ) ] 



I ,CLASS=/ (cl[ ,cl]...) 
I iDASD 

iTAPE 
TERM 
GRAF 
DRI 
ORO 



I ,ADAPTER= 



BSCA 

IBHI 

TELE2! 

TYPEI 

TYPE2 



[ , SETADDE=sadnum ] 
r T 

I (EP 

I ,CPTYPE=/NCP 

I (PEPn 

L J 

;pname ] 
:nn ] 
=cuu] 
=label] 



,CPNAME=ci 
,HAXDIAL=I 
,BASEADD=< 
,CLUSTER=] 



li 
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w h er e : 

ADDRESS=|cuu 1 
\ (cua,nn) ) 
is the real I/O device address or (addresses) . 

The address, cuu, is three hexadecimal digits from 000 to FFF. The 
high order digit is the address of the channel to which the device 
is attached. The low order two digits represent the control unit 
and device address. 

The value, nn, is the number of RDEVBLOK entries to be generated; 
it may be any number from 1 to 256. For example, if ADDRESS= (10, 5) 
is specified, RDEVBLOKs with device address 10, 11, 12, 13, and 14 
are generated. If nn is omitted, a value of 1 is assumed for all 
devices except the 2314 and 2305, which have a default value of 8. 

If DEVTYPE=3066 or 3158, nn can only be 1 because only one 3066 or 
only one 3158 can be specified for each RDEVICE macro. 

DEVTYPE=type 

is the type of device. 

The device type can be ICA, CTCA, 1017, 1018, 1052, 1053, 1403, 

1442P, 1442R, 1443, 2150, 2250, 2260, 2265, 2301, 2303, 2305, 2311, 

2314, 2319, 2321, 2401, 2402, 2403, 2404, 2415, 2420, 2495, 2501, 

2520P, 2520R, 2540P, 2540R, 2671, 2701, 2702, 2703, 2955, 3066, 

3158, 3210, 3211, 3215, 3277, 3284, 3286, 3330, 3333, 3340, 3410, 
3411, 3420, 3505, 3525, 3704, or 3705. 

Co^iaa Considerations 

For 2741 or 3767 devices (comparably equipped for 2741 operation) , 

specify 2702 or 2703 as the device type. 

For the following devices, which have no device type, specify: 

I • ICA for Integrated Communications Adapter 

• CTCA for Channel-to-channel Adapter 

The system console must be specified in both the RDEVICE and 
RCTLUMIT macros. Specify the system console in both macros as 
follows: 

SYstem/370 Model System Console 

135, 145, 155 II 3210 or 3215 

158 3158 (if it is in display mode) or 

3215 (if it is in printer-keyboard 
mode and has the 3213 Printer Model 1) 

165 II, 168 3066 

The device types, 2540R and 2540P, refer to the same IBM 2540 Card 
Read Punch (as do 1442P and 1442R, and 2520P and 2520R) . Each 
logical device must be specified in a separate RDEVICE macro. 

In addition, any other device that can be attached to a real 
System/370 can be specified in the RDEVICE macro by its device 
type. Any device type code that does not appear in the list of 
supported devices in the "Configurations" section of Part 1 is an 
I unsupported device. For unsupported devices that do not have a 
I device type listed under the DEVTYPE operand, you should code the 
subclass on the CLASS operand. Then unsupported devices can be 
dedicated to a virtual machine, and CP can log the error 
recordings, if there are any. CP does not use unsupported devices 
for its own operations. 
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If a device specified in the RDEVICE macro is not supported by 
VM/370, the following MNOTE message (warning level) is generated: 

UNSUPPORTED DEVICE TYPE 

The device is generated as a unsupported device. An unsupported 
device can only be used if it is dedicated to a virtual machine. It 
is dedicated to a virtual machine if a DEDICATE control statement 
is coded in the VH/370 directory for the virtual machine, or if it 
is attached to it by the CP ATTACH command. 

MODEL=model 

is the model number, if any, of a 2305, 3330, 3333, 3704, or 3705 
device, or a tape device. 

model is a value that can be: 

1 or 2 for a 2305 device. 

1, 2, OT 11 for a 3330 device. 

1 or 1 1 for a 3333 device. 

1, 2, 3, 4, 5, 6, 7, or 8 for a 3704 or 3705 device. 

1, 2, 3, 4, 5, 6, 7, or 8 for a tape device. 

FEATURE=(feature[ , feature]. . .) 

are the device's optional features. These features can be written 
in any order. These features are: 

Feature Ex£lanation 

7-TRACK 7-track head on a tape drive 

CONV Conversion feature on a 7-track tape drive 

DUALDENS Dual density on a tape drive 

OPRDR Operator identification card reader on a 3277 Model 2 

TRANS Translation feature on a 7-track tape drive 

UNVCHSET Universal character set printer 

2CHANSW Two-channel switch feature for tape or DASD drive 

4CHANSW Four-channel switch feature for tape or DASD drive 

Coding Considerations 

To allow CMS to correctly verify tape mode set operations, the 

correct feature code for a tape device must be specified. 

If the 3277 display device is equipped with the optional operator 
identification card reader, then the virtual machine operator can 
gain access to the system (log on) only if he inserts a 
magnetically encoded card. Use the FEATUHE=OPRDR operand of the 
RDEVICE macro to specify a 3277 device with a card reader. If you 
do not want access authorization by a card reader, do not code 
FEATURE=OPRDR in the RDEVICE macro. FEATURE=OPRDR is invalid if 
DEVTYPE=3158. 

If the hardware configuration includes a Two- or Four-Channel 
Switch feature, each device on the switchable control unit must be 
generated with FEATURE=2CHANSH or FEATURE=4CHANSH coded on the 
RDEVICE macro. 

CLASS=/ (cl[ ,cl]...) 

DASD 
ITAPE 
'TERM 
JGRAF 
'URI 

URO 

is the device class; either the output spooling class or a special 
subclass for unsupported devices. 
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OJitfiut S£oolinc[ Classes 

The spooling classes (cl, cl ...) list up to four output spooling 
classes separated by connas. This fori of the CLASS operand can 
only be specified for a 1403, 1443, or 3211 printer, or 2520P, 
2540P or 3525 card punch. The spooling class, cl, is one alphaaeric 
character. If you specify more than one class, you lust separate 
thea by commas. If no class is specified, class h is assuaed for 
printers and punches. 

Coding Considerations: The following inf or nation should be helpful 
when you code this operand: 

• For more inforiation about spooling classes, see the YM/370 : 
OE§E§^or^s Guide. 

• The class is used by the CP START conaand and nay be changed by 
this comnand. For a complete description of the START command, 
see the YH/370: Command Language Guide for General Ogers. 

• A class C punch should be included if accounting cards are 
desired. 

Subclass for Dnsu^ported Devices 

Specify a device subclass only for unsupported device types. CP 
uses the subclass when it translates virtual CCW strings directed 
to unsupported devices. This form of the CLASS operand is valid 
only if the device type specified on the DE?TYPE operand does not 
appear in the list of valid device types. 

The subclasses are: 

DASD Direct Access Storage Devices 

TAPE Tape devices 

TERM Terminals 

GRAF Display mode terminals 

URI Unit record input devices 

URO Unit record output devices 

You must determine the correct subclass to specify for any device 
type that does not appear in the list of valid device types under 
the DEVTYPE operand. Do not code a subclass for any device type 
that appears in that list. For example, a 1287 Optical Reader is 
an unsupported device for VM/370. It does not appear in the list 
of supported devices in Part 1 and is not listed as a device type 
for the DEVTYPE operand of the RDEVICE macro. However, you can 
define a 1287 and use it if you dedicate it to a virtual machine. 
You must decide the correct subclass. For example, 

RDEVICE ADDRESS=010,DEVTYPE=1287,CLASS=URI 

defines a 1287 Optical Reader at address 010. The 1287 belongs to 
the unit record in^ut (URI) subclass. 

Note: If you use this form of the CLASS operand and the unsupported 
device does not function properly, try dedicating the device to a 
virtual=real machine and inhibiting CCW translation (by issuing SET 
NOTRANS ON) . Note that a maximum of twenty-four sense bytes can be 
contained in the RDEV6L0K created for an unsupported device. 
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adapter=(bsca ) 

IBM 1 

TELE2 

TYPE1 

TYPE2 
is the terainal control or transmission adapter used to connect a 
telecommunications I/O device to its control unit. This operand is 
required if a DBVTYPE of 2701, 2702, 2703, 3704, 3705, or ICA is 
specified, and is ignored if specified for any other device type. 

BSCA specifies an IBM Binary Synchronous Terminal Adapter Type II 
for a 2701, or an IBM Binary Synchronous Terminal Control Type II 
for a 2703, 3704, or 3705. 

IBM1 specifies that an IBM Terminal Adapter Type I attaches a 1050 
or 2741 to a 2701, or that an IBM Terminal Control Type I attaches 
a 1050 or 2741 to a 2702 or 2703, or that a Line Interface Base 
Type I attaches a 1050 or 2741 to a 3704 or 3705. 

TELE2 specifies that a CPT-TWX (Models 33/35) Terminal attaches to 
a Telegraph Terminal Adapter Type II in a 2701, or to a Telegraph 
Terminal Control Type II in a 2702 or 2703, or to a Line Interface 
Base Type I in a 3704 or 3705. 

TYPE1 or TYPE2 specifies the channel adapter accessed by a 3704 or 
3705. If TYPE2 is specified, CPTYPE should also be specified. 

SETADDR=sadnum 

is the set address (SAD) command to be issued for a 
telecommunications line attached to a 2702, 3704, or 3705 control 
unit. This operand is required if the device is a 2702. 



Sadnum 




Value 



Command 
SADZEBO 


1 


SADONE 


2 


SADTNO 


3 


SADTHREE 


4 


(no SAD command is issued) 



CPTYPE=(EP ) 
NCP> 



>EP) 

is the 3704/3705 control program to be run in a 3704 or 3705 
Communications Controller. 

EP specifies the 2701, 2702, or 2703 Emulation Program. 

NCP specifies the Network Control Program. 

PEP specifies the Partitioned Emulation Program. 

Hot es : 

1. If you want any of these three control programs to be able to 
execute, either omit the CPTYPE= operand or specify EP. If 
CPTYPE=NCP or PEP is specified, an Emulation Program cannot be 
loaded successfully. 

2. If ADAPTER=TYPE2 is specified, you must code the CPTYPE 
operand. 
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CPNAH£=cpnane 

is the one- to eight-character naae of a 3704/3705 control program 

that is to be automatically loaded in the 3704 or 3705 at IPL tine. 

If an automatic load is not desired, oait this operand. 

MAXDIAL=nn 

is a one- or two-digit decinal nunber indicating the aaxiiaa nuaber 
of 2701, 2702, or 2703 eiulation lines that lay be active at any 
one tiae. The RDEVICE aacro generates this nuaber of additional 
BDEVBLOKs to accoaaodate these emulation lines. 

BASEADD=cuu 

is the native address (load address) of the 3701/3705 that controls 
the physical line (s) . This operand is required for correct 
operation of VM/370 recovery aanageaent for emulation lines based 
on a 3704/3705. This operand is valid only if ADAPTER=IBM1 (or 
=TELE2 or =BSCA) . 

I CLOSTER=label 

I is the label of the CLUSTER macro that defines the clustered or 

I standalone station attached to this line. 

Examjole s : 

The following examples illustrate the use of the RDEVICE macro 
instructions to describe a 1403 printer with the Universal Character set 
(DCS) feature, four 9-track, 800 bpi tape drives, and eight CPT-TWX 
lines on a 2702. 

RDEVICE ADDRESS=00E,DEVTYPE=1403,FEATORE=UNVCHSET, 

CLASS=(A,C) 
RDEVICE ADDHESS= (0C0,4) , DEVTYPE=2401 
RDEVICE ADDRESS=(030,8) ,DEVTYPE=2702 , ADAPTER=TELE2, 

SETADDR=2 



MHOTE Messages: 

The following MNOTE messages may be generated by the RDEVICE macro 
instruction. 

INVALID DEVICE ADDRESS 

indicates that one or more of the device addresses coded was 
specified incorrectly. If DEVTYPE=CTCA, the device address must be 
in the form cuO , for example, 270. 

UNSUPPORTED DEVICE TYPE 

indicates that the device specified is not supported by VM/370. It 
is generated as a non-supported device, and can be used only if it 
is dedicated to a virtual machine. 

MORE THAN 256 DEVICES 

indicates that a value greater than 256 was specified in the number 
parameter of the ADDRESS operand; or that the base address plus the 
number of devices specified generate an address greater than 
X'FF' . 

INVALID MODEL NUMBER 

indicates that the model number specified was not a permitted 
specification. 

INVALID ADAPTER TYPE 

indicates that the adapter specified was not a permitted 
specification, or that the ADAPTER operand was not coded. 
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INVALID SETADDR VALUE 

indicates that the SETADDB value specified is not a permitted 
specification, or that the SETADDR operand was not coded for a 2702 
device. 

INVALID FEATURE SPECIFIED 

indicates that the feature specified is not a permitted 
specification. 

INVALID CLASS PARAMETER 

indicates that an invalid form of the CLASS operand was specified, 
or that the CLASS operand was specified for a device to which it is 
not applicable. 

RDEVICE MACRO OUT OF SEQUENCE 

indicates that the RDEVICE macros are not in their proper position 
in the real I/O configuration file. 

ONLY ONE 3066 OR 3158 CONSOLE ALLOWED 

indicates that the ADDRESS= (cuu,nn) operand is invalid. The value 
nn cannot be greater than one because only one 3066 can be coded on 
a RDEVICE macro and only one 3158 can be coded on a RDEVICE macro. 

I MORE THAN 16 TP CONCENTRATORS AND LINES 

I indicates that more than the maximum of 16 binary synchronous lines 

I are defined to support remote 3270 configurations. 

I INVALID 'CLUSTER' OPERANDS 

I indicates that the CLUSTER operand is specified incorrectly; a 

I valid assembler language label must be specified. 

If any of the above errors (other than UNSUPPORTED DEVICE TYPE) are 
detected, the real device block is not generated. 



^^il 1§22I^ Error Messages 

The RDEVICE macro instruction generates an entry in a table of printers 
or a table of punches or a table of readers for spooling when 
DEVTYPE=ia03, 3211, 1UU3, 25U0P, 3525, 2540R, 3505, or 2501 is 
specified. Each table has a maximum of 32 entries; one of the following 
messages results if more than 32 readers, printers, or punches are 
specified. 

MORE THAN 32 READERS 
MORE THAN 32 PRINTERS 
MORE THAN 32 PUNCHES 

If any of these messages prints, it indicates that the RDEVBLOK is 
generated, but no entry is made in the printer or punch table; the 
device cannot be used for CP spooling. 
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3704/3705 Error Messages 

The BDE7ICE Macro instruction generates an entry in a table of 
prograMiable coiaunications controllers when DE?TYPE=370U or 3705 is 
specified. This table can have a Baxinun of 10 entries; the following 
message results if lore than ten 370U or 3705 devices are specified: 

MORE THAH 10 TP CONCENTRATORS 

If this nessage prints, it indicates that the RDEVBLOK is generated, but 
no entry is nade in the Prograiaable Connunications Controller table. 
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RCTLONIT MACRO 

Use the RCTLUNIT macro to generate a real control unit block (RCOBLOK) . 
One RCTLUNIT macro must be specified for each real control unit. The 
maximum number of real control units is 511, providing you have enough 
real storage to hold the real control unit blocks (RCUBLOKs) . Control 
units generally fall into two categories: those supporting eight or 
fewer devices, and those supporting more than eight devices. 

A control unit that supports eight or fewer devices must be assigned 
an address that is divisible by eight. All devices with an address 
equal to the control unit's address (the base address) or any of the 
next seven sequential addresses are mapped to this control unit. For 
example, devices with addresses of 018 through OIF are mapped to a 
control unit with address 018. 

On a multiplexer channel, several device addresses may fall within 
the address range of one RCTLUNIT macro. When this occurs, only one 
RCTLUNIT macro may be coded, even though more than one real control unit 
is present. For example, a system console at address 009, a 2540 reader 
at address OOC and a 2540 punch at address OOD would be defined in a 
single RCTLUNIT macro with a control unit address of 008, even though 
the system console and the 2540 card reader punch have different real 
control units. In this case, any valid control unit type can be coded. 
The only exception to this is that control units that operate on a 
shared subchannel must be specified by separate RCTLUNIT macros. 

For control units supporting a range of more than eight device 
addresses, use the FEATURE= operand. The base address must be divisible 
by sixteen. All devices from the base address up to the number of 
devices specified by the FEATURE= operand are mapped to the specified 
control unit. When a control unit has the hardware feature that allows 
it to support more than eight devices, the RCTLUNIT macro must specify 
FEATURE=xxx-DEVICE, where xxx is the number of addressable devices that 
can be attached to this control unit. The number of devices specified 
must be divisible by sixteen and rounded to the next higher increment of 
sixteen if not divisible. The maximum number of devices that can be 
attached to a control unit is 256. 

For example, if you have a 3830 control unit with the 32-device 
feature installed, you must specify FEATURE=32-DEVICB for it, even if 
fewer than thirty-two 3330s are installed. 

A device that attaches directly to the channel without a separate 
control unit must still have a RCTLUNIT macro coded for it. For 
example, if a 3210 is defined with an RDEVICE macro, it must have a 
corresponding RCTLUNIT macro. 

The RCTLUNIT macro instructions describing the control units for your 
installation's computing system may be in any order, but they must be 
contiguous and follow all of the RDEVICE macro instructions in the 
module DHKRIO. The first RCTLUNIT macro instruction also generates the 
label DHKRIOCU, which indicates the start of the real control unit 
blocks to CP. 

The name field may not be specified for the RCTLUNIT macro 

instruction; if a name is specified it is ignored. The macro generates 

a name by appending the control unit address to the characters RCU. For 

example, if the control unit address is 230, the name RCU230 is 
generated. 
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The format of the RCTLOHIT nacro is: 

Nane | Operation | Operands I 

1 



RCTLUNIT I ADDRESS=address 
I ,CDTYPE=type 
I [,PEATDRE=xxx-DEVICE] 



where; 

ADDRESS=address 

is the real address of the control unit. The address consists of 
three hexadecimal digits. The high order digit is the channel 
address of this control unit. The low order two digits must be the 
lowest address of the control unit. The first digit may be any 
hexadecimal number from to F. If the xxx-DEVICE feature is 
supported, the low order digit must be 0. Otherwise, it may be 
either or 8. 

Note: If your installation has a 2701, 2702, or 2703, and a 370U or 
3705 executing in emulation mode, you must be sure that their 
addresses are not the same. 

COTYPE=type 

is the device type of the control unit. One of the following 

device type numbers can be specified: 1052, 1442, 2150, 2250, 2314, 

2319, 2403, 2404, 2415, 2495, 2501, 2520, 2701, 2702, 2703, 2803, 

2804, 2820, 2821, 2822, 2826, 2835, 2840, 2841, 2844, 2845, 2848, 

2955, 3066, 3158, 3210, 3215, 3272, 3277, 3345, 3411, 3505, 3525, 
3704, 3705, 3803, 3811, 3830, ICA, IFA, ISC, CTCA. 

In addition, any other control unit that can be attached to a real 
System/370 may be specified in an RCTLUNIT macro instruction by its 
device type. 

Even though some devices attach directly to the channel without a 
separate control unit, an RCTLUNIT macro instruction must be 
included for them. For example, if you want to define a 3215, you 
must code an RDEVICE and RCTLUNIT macro for the 3215; even though 
the 3215 does not require a control unit, it requires a RCTLUNIT 
macro. 

FEATURE=xxx-DEVICE 

is the optional control unit feature. The feature, xxx-DEVICE, 

indicates that the control unit is controlling more than eight 

devices. The prefix, xxx, can be 16, 32, 48, 64, 80, 96, 112, 128, 

I 144, 160, 176, 192, 208, 224, 240, or 256. "Appendix B: 

I Configuration Aid" lists the maximum number of devices that may be 

I specified for each control unit. This feature may be specified for 

I a 2403, 2702, 2703, 2803, 2835, 3272, 3345, 3704, 3705, 3803, 3830, 

ICA, or ISC. 

For any unsupported control unit, FEATURE=16-DEVICE is valid and is 
the maximum you can specify. Unsupported control units are any 
that do not appear in the "Configurations" section of Part 1. 
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Ex aB£les : 

The following examples illustrate the use of the RCTLONIT macro 
instruction to describe the control units for: a 3215 console 
printer-keyboard with address 009^ a 2314^ and a 3705 with lines 040 
through 04B. 

RCTLUNIT ADDRESS=008,CUTYPE=3215 
RCTLUSIT ADDRESS=230,CUTYPE=2314 
RCTLONIT ADDRESS=040,CDTYPE=3705,FEATORE=16-DEVICE 

MNOTE Messages: 

The following MNOTE messages may be generated by the RCTLONIT macro 
instruction. 

INVALID DEVICE CONFIGORATION 

indicates that CDTyPE=CTCA was specified, but there was more than 
one RDEVICE macro defining devices on the control unit. 

INVALID CONTROL ONIT ADDRESS 

indicates that either the channel or control unit portion of the 
address is not in the range to F, or that the last digit of the 
address is neither nor 8, or that the control unit portion plus 
the number of devices specified is greater than 256. 

INVALID CONTROL ONIT ADDRESS FOR SPECIFIED FEATORE 

indicates that FEATORE=xxx-DEVICE is specified but that the last 
digit of the control unit address is not 0. 

INVALID CONTROL ONIT TYPE FOR SPECIFIED FEATORE 

indicates that FEATURE=xxx-DEVICE is specified but the type number 
is not valid for the specified feature. 

INVALID FEATORE SPECIFIED 

indicates that the argument of the FEATORE= keyword is not 
16-DEVICE to 256-DEVICE in increments of 16. 

RCTLONIT MACRO OOT OF SEQOENCE 



fJLX. C= XM\ 



in the real I/O configuration file. 

If any of the above errors are detected, the real control unit block 
is not generated. This results in undefined symbols in the real device 
blocks for this control unit. 
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RCHANNEL MACRO 



Use the RCHAH8EL macro to generate a real channel block (RCHBLOK) . An 
RCHANNEL macro instruction must be coded to define each real channel in 
the I/O configuration. 

The RCHANNEL macro instructions describing the channels for your 
installation may be in any order, but they must be contiguous and follow 
all of the RCTLUNIT macro instructions in the module DMKRIO. The first 
RCHANNEL macro instruction also generates the label DMKRIOCH, which 
indicates the start of the real channel blocks to CP. 

Ho name is specified for the RCHANNEL macro instruction; if a name is 
specified, it is ignored. The RCHANNEL macro generates a name by 
appending the channel address to the characters RCHAN. For example, if 
the channel address is 2, the name RCHAN2 is generated. 

The format of the RCHANNEL macro is: 



Name 



Operation 



RCHANNEL 



Operands 



ADDRESS= address 
,CHTYPE=( SELECTOR 

J MULTIPLEXOR 
IBLKMPXR 



whe re : 

A DDR ESS= address 

is the real address of the channel. It is a hexadecimal number from 
to F. 

chtype=(selector ) 
<^ multiplexor v 
(blkmpxr ) 
is the type of channel. 

SELECTOR indicates a selector channel. 

MULTIPLEXOR indicates a byte-multiplexer channel. 

BLKMPXR indicates a block multiplexer channel. 

Ex am£l es : 

The following examples illustrate the use of the RCHANNEL macro 
instruction to describe a multiplexer channel whose address is 0, a 
selector channel whose address is 1 , and a block multiplexer channel 
whose address is 2. 

RCHANNEL ADDRESS=0,CHTYPE=MULTIPLEXOR 
RCHANNEL ADDRESS=1 ,CHTYPE=SELECTOR 
RCHANNEL ADDRESS=2 ,CHTYPE=BLKMPXR 
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RCHAHNEL Macro 

MNOTE Messages: 

The following HNOTE messages nay be generated by the RCHANNEL macro 
instruction : 

INVALID CHANNEL ADDRESS 

indicates that the channel address specified is not in the range 
0-F. 

INVALID CHANNEL TYPE 

indicates that the channel type specified is neither MOLTIPLEXOR- 
BLKMPXR, nor SELECTOR. 

RCHANNEL MACRO OUT OF SEQUENCE 

indicates that the RCHANNEL macros are not in their proper position 
in the real I/O Configuration file. 

If any of the above errors is detected, the real channel block is not 
generated. This results in undefined symbols in the real control unit 
blocks for this channel. 
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RIOGEN Macro 



RIOGEN MACRO 

Use the RIOGEN nacro instruction to generate the channel index table and 
unit record and console tables. It must appear as the last macro 
instruction before the END statement in the DMKHIO file. 

The name field must not be specified for the RIOGEN macro. The 
format of the RIOGEN macro is: 



I Name | Operation | Operands 



RIOGEN I CONS=XXX 

I [ ,ALTCONS=XXX ] 



w h er e : 

CONS=address 

is the address of the VM/370 primary system console. The address 
is a hexadecimal device address that was previously specified in an 
RDEVICE macro entry. This device must be either a 3066, 3210, 
3215, or 1052 (via a 2150 freestanding console), a System Console 
for the 3158 (in printer-keyboard mode with the 3213 Printer Model 
1 reguired, or in display mode), 7412, or a 3277 (local 
attachment) . 

ALTCONS=address 

is the address of the alternate console. The address is a 
hexadecimal device address that was previously specified in an 
RDEVICE macro instruction. This device, which should be located as 
close as possible to the primary system console, may be any device 
supported as a VM/370 logon device (except for those remote 
terminals connected via 3704/3705 Communication Controllers) . This 
console is used if the primary system console is unavailable at 
initial program load time. If ALTCONS is not coded or the alternate 
console is not available, CP enters a disabled wait state with a 
wait state code of X'005' in the instruction address register 
(lAR) . 

Codinc[ Considerations ; The alternate console must not be a 
telecommunications line on a real IBM 3704/3705 Communications 
Controller. 

If the alternate console is an IBM 2741 Communication Terminal, or 
3767 Communication Terminal (operating as a 2741) , it must use the 
EBCDIC transmission code. 

Ex am£l es : 

The following examples define a primary system console (OIF) with an 
alternate console (050) , and a system console (009) with no alternate 
console. 

RIOGEN CCNS=01F,ALTCONS=050 
RIOGEN CONS=009 
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I MAMPIjJ 21 CODING REAL I/O CONFIGURATION FILE (DMKRIO) 

I In this example, macros are coded to support the following real devices: 

1 2540 Card Reader/Punch 

1 3505 Card Reader 

1 3525 Card Punch 

2 1403 Printers with the Universal Character Set feature 
1 3211 Printer with the Universal Character Set feature 
1 3215 Console Printer-Keyboard 

1 2955 

2 3705 Communications Controllers (one with an IBM1 adapter and 
the other with a BSCA adapter) 

2 2702 Transmission Control Units (with one that supports Teletype 

terminals) 
1 2314 Direct Access Storage Facility with 8 modules 

1 2305 Fixed Head Storage with 8 drives 

2 3330 Disk Storage (One unit has eight modules and the other has 
ten. The unit with ten modules has eight of them switchable 
between two channels.) 

1 2401 Magnetic Tape Unit with 4 tape drives 

1 3410 Magnetic Tape Unit, Model 3, with 1 tape drive 

1 3420 Magnetic Tape Unit, Model 7, with 2 tape drives 

1 Multiplexer channel 

4 Block multiplexer channels 

1 Channel-to-Channel Adapter 

Figure 16 shows the real configuration. 
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3705 

Communications 
Controller 




3411 
Magnetic 
Tape Unit 
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3410 
Tape 
Drive 



Channel to- 
Channel Adapter 



470 



2403 

Magnetic 
Tape Unit 
and Control 



-470 

2401 Tape Drives 
-473 



The real I/O configuration file that supports this example is: 
DMKRIO CSECT 

TsiMsn Tr-'o » r-.TMi T? c o — r* nr- TWtrfr vrsi? — O C/i f^B 

RDEVICE ADDBESS=00D,DEVTYPE=25U0P,CLASS=(X,A) 

RDEVICE ADDRESS=00E,DEVTYPE = 1403, CLASS= (X ,A) ,FEATDRE=UNVCHSET 

RDEVICE ADDRESS=00F,DEVTYPB=1403, CLASS= (S) , FEATURE = DNVCHSET 

RDEVICE ADDRESS=002,DEVTYPE=3211, CLASS= (X,A) ,FEATURE=ONVCHSET 

RDEVICE ADDRESS=012rDEVTYPE=3505 

RDEVICE ADDRESS=013,DEVTYPE=3525,CLASS= (X,A) 

RDEVICE ADDRESS=01F,DEVTYPE=3215 

RDEVICE ADDRESS=080,DEVTYPE=2955 

RDEVICE ADDRESS=0B0,DEVTYPE=3705,ADAPTER=IBM1 

RDEVICE ADDRESS=(130,8) ,DEVTYPE=2314 

RDEVICE ADDRESS=270,DEVTYPE=CTCA 

RDEVICE ADDRES3=320,DEVTYPE=3705,ADAPTEE=BSCA 

RDEVICE ADDRESS=3D0,DEVTYPE=CTCA 

RDEVICE ADDRESS=2D0,DEVTYPE=2305,MODEL=2 

RDEVICE ADDRESS= (250, 10) , DEVTYPE=3330, FEAT0RE = 2CHANSS 

RDEVICE ADDRESS=(350,8) ,DEVTYPE=3330 

RDEVICE ADDRESS= (358,2) , DEVTYPE=3330, MODEL= 1 1 

RDEVICE ADDRESS= (470,4) ,DEVTYPE=2401 ,FEATORE=BOALDENS, M0DEL=5 

RDEVICE ADDRESS= (040, 16) , DEVTYPE=2702, ADAPTER = IBM 1 , SETADDR=2 

RDEVICE ADDRESS=(050,14) ,DEVTYPE=2702 , ADAPTER=IBM1 ,SETADDR=2 

RDEVICE ADDRESS=0 5E,DEVTYPE=2702,ADAPTER=TELE2,SETADDR=1 

RDEVICE ADDRESS=(330,8) ,DEVTYPE=3330,FEATDRE=2CHANSH 

RDEVICE ADDRESS=390,DEVTYPE=3410,FEATORE=DOALDENS,MODEL=3 

RDEVICE ADDRESS=(380,2) ,DEVTYPE=3420,FEATURE=DUALDENS, M0DEL=7 

RCTLUNIT ADDRESS=000,CUTYPE=3811 

RCTLUNIT ADDRESS=008,CUTYPE=2821 

RCTLUNIT ADDRESS=0B0,CUTYPE=370 5,FEATDRE=16-DEVICE 

RCTLUNIT ADDRESS=270,CUTYPE=CTCA 

RCTLUNIT ADDRESS=320,CUTYPE=3705 

RCTLUNIT ADDRESS=3D0,CUTYPE=CTCA 

RCTLUNIT ADDRESS=010,CUTYPE=3505 

RCTLUNIT ADDRESS=018,CUTYPE=3215 

RCTLUNIT ADDRESS=040,CUTYPE=2702,FEATURE=16-DEVICE 

RCTLUNIT ADDRESS=050,CUTYPE=2702,FEATURE=16-DEVICE 

RCTLUNIT ADDRESS=080,CUTYPE=2955 

RCTLUNIT ADDRESS=130,CuTYPE=2314 

RCTLUNIT ADDRESS=470,CUTYPE=2403 

RCTLUNIT ADDRESS=2D0,CUTYPE=2835 

RCTLUNIT ADDRESS=250,CUTYPE=3830,FEATURE=16-DEVICE 

RCTLUNIT ADDRESS=350,CUTYPE=3830,FEATURE=16-DEVICE 

RCTLUNIT ADDRESS=330,CUTYPE=3830 

RCTLUNIT ADDRESS=380,CUTYPE=3803 

RCTLUNIT ADDRESS=390,CUTYPE=3411 

RCHANNEL ADDRESS=0,CHTYPE=MULTIPLEXOR 

RCHANNEL ADDRESS= 1 , CHTYPE=BLKMPXR 

RCHANNEL ADDRESS=2,CHTYPE=BLKMPXR 

RCHANNEL ADDRESS=3 , CHTYPE=BLKMPXR 

RCHANNEL ADDRESS=4,CHTYPE=BLKMPXR 

RIOGEN CONS=01F,ALTCONS=050 

END 
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Preparing the CP System Control File (DMKSYS) 



The CP systei control file consists of macros that describe the CP 
system residence device, the system storage size, the CP-owned direct 
access devices, the system operator's user identification, and the 
proper system timer value. The file should be placed in the card reader 
in the order shown: 



DMKSYS 


CSECT 






SYSOHN 


macro 




SYSRES 


macro 




SYSOPR 


macro 




SYSCOR 


macro 




SYSTIME 


macro 




SYSLOCS 


macro 




END 





Note: Samples of the DMKSYS and DMKSNT files are provided with the 
starter system. If you use these, you can save the CMS system at the 
end of the system generation procedure. VM/370 prompts you to tell it 
if you want the sample DMKSYS file punched. You may modify this file if 
you wish. For example, you could modify the starter system DMKSYS file 
to add other CP-owned volumes. 

The DMKSYS module supplied with the 2314 starter system is: 

DMKSYS CSECT 

SYSOWN (VMREL2,TEMP) 

SYSRES SYSVOL=VMREL2,SYSRES=131,SYSTYPE=2314,SYSNDC=3, ] 

SYSHRM=6,SYSERR=7 
SYSCOR RMSIZE=512K 

SYSOPR SYSOPER=OPERATOR,SYSDOMP=OPERATOR 
SYSTIME Z0NE=4,L0C=WEST,ID=EDT 
SYSLOCS 
END 

The DMKSYS module supplied with the 3330 starter system is: 

DMKSYS CSECT 

SYSOWN (VMREL2,TEMP) 

SYSRES SYSVOL=VMREL2,SYSRES=131 ,SYSTYPE=3330,SYSNUC=2, ] 

SYSWRM=4,SYSERR=5 
SYSCOR RMSIZE=512K 

SYSOPR SYSOPER=OPERATOR, SYSDUMP=OPERATOR 
SYSTIME ZONE=a,LOC=WEST,ID=EDT 
SYSLOCS 
END 

The DMKSYS module supplied with the 33U0 starter system is: 

DMKSYS CSECT 

SYSOWN (VMREL2,TEMP) 

SYSRES SYSVOL=VMREL2,SYSRES=131 ,SYSTYPE=3340,SYSNUC=3, : 

SYSWRM=8,SYSERR=9 
SYSCOR RMSIZE=512K 

SYSOPR SYSOPER=OPERATOR,SYSDUMP=OPERATOR 
SYSTIME Z0NE=4,L0C=WEST,ID=EDT 
SYSLOCS 
END 
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PERFORMANCE CCSSIDERATIOHS FOR CODING THE DMKSYS FILE MACROS 

The following recoBnendations may help reduce arm and channel contention 

aiiu uiajr j.u^i.v/vc: uuc ^ci. j.«.i j. uia uv^c ui. a i a/ j i \j fijoT^cuia 

• Provide separate CP volumes for paging and spooling and have the 
volumes mounted on separate channels. 

• If you have a heavy I/O production virtual machine (for example, one 
that is executing OS/VSl or DOS/VS) , try to keep all its major I/O 
devices on a separate channel from a channel handling the CMS system 
residence volume or other user's disks. 

• Try to keep read-only minidisks (for example, the CMS system 
residence disk, source disks) that are frequently accessed on 
separate volumes from users' read/iirite minidisks. If possible, also 
keep them on separate channels. 

• If your installation is likely to have a large number of CMS users 
active at one time, you should distribute the CMS activity over two 
volumes by (1) setting up a second CMS system residence volume and 
dividing the users between the two CMS system residence volumes or 
(2) putting your program products on one spindle and the CMS 

non-resident commands on another spindle. 
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SYSOHN Macro 



SYSOWN MACRO 



Use the SYSOWM macro to generate the list of CP-owned DASD volumes. A 
CP-owned volume is either the CP system residence volume, or a volume 
that contains VM/370 paging, spooling, or temporary disk space. It must 
contain a CP allocation talsle at cylinder 0, record 4 allocating these 
areas. Even if a volume has a VM/370 allocation table at cylinder 0, 
record 4, allocation data is ignored unless the volume appears as an 
operand in the SYSOWN macro instruction. 

SEecial Considerations for Allocating Space on CP^Owned Volumes: The 
following considerations should help you to allocate space efficiently 
on CP-owned volumes: 

• If a volume is specified in a SYSOWN statement but is not mounted 
when the generated system is loaded (via the IPL command) , that 
volume is considered unavailable to VM/370. Processing continues, if 
possible. The operator can mount and attach the volume later, if it 
is needed. 

• Only those volumes that contain paging and spooling space or TDSK 
space need be identified as CP-owned volumes. All other volumes are 
described either by directory entries or by logically attaching the 
entire device. 

• If you add another volume to the SYSOWN list, you must add it at the 
end of the list. (Otherwise, if you attempt a warm start after 
regenerating and loading CP, the relative entry number used to locate 
system spool buffers is incorrect.) Then reassemble DMKSYS, rebuild 
the CP nucleus, and reload it on the system residence volume. Use 
the GENERATE EXEC procedure to reassemble DMKSYS and reload the CP 
nucleus. 

• If your installation has saved systems (systems that can be loaded by 
name, thus bypassing the initial program load procedure), you must 
reserve space on a CP-owned volume to hold the named systems you want 
saved. The DASD space you reserve, for each named system you wish to 
save, should be enough to contain the number of pages specified in 
the SYSPGCT operand of the NAMESYS macro, plus one page for system 
use. 

• If your VM/370 system has a 3704 or 3705, you must reserve space on a 
CP-owned volume to contain the 370t»/3705 control program image. See 
the "Generating a VM/370 System that Supports the 370U/3705" section 
of Part 1 for information about how much DASD space you should 
reserve. 

The name field must not be specified for the SYSOWN macro. 

The format of the SYSOWN macro is: 



Name 



Operation 



SYSOWN 



Operands 



r T r T 

(volid IxTEMPI) [,(volid lxTEMP|) 

|,PAGE| |,PAGE| 

L J L J 
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SYSOWN Macro 



where : 
volid 



is the CP-owned volume identification, up to six alphameric 



r 1 
I^TEMPI 
I , PAGE I 

L J 

indicates to VM/370 how allocatable space on the specified volume 
should be used. 

TEMP specifies that this volume is to be used for temporary and 
spool space allocation, and should only be used for paging space if 
all volumes normally used for paging allocation are full or 
unavailable. TEMP is the default option. (TEMP space must be 
formatted by the CP Format/Allocate service program.) 

PAGE specifies that this volume is to be used for paging and 
temporary disk allocation only. 

Example : 

The following SYSOWN macro designates the CPDRN1 volume as paging space 
and the CPDSK1 and CPDSK2 volumes as temporary space: 

SYSOHN (CPDHM1 ,PAGE) , (CPDSK 1,TEMP) ,CPDSK2 

MNOTE Messages: 

The following MNOTE messages may be generated by the SYSOHN macro 
instruction: 

INVALID PREFERENCE OPTION 

indicates that the second positional sublist parameter following 
volid is not TEMP or PAGE. 

MORE THAN 255 VOLUMES SPECIFIED 

indicates that more than 255 CP-owned volumes are specified in the 
SYSOHN macro instruction. 

DUPLICATE VOLUME SERIAL SPECIFIED 

indicates that the same volume serial number is specified more than 
once. 

NO VOLUMES SPECIFIED 

indicates that the SYSOHN macro instruction is specified without 
any positional parameters. 

HARNING - NO TEMP SPACE SPECIFIED 

indicates that no volume is specified as being preferred for TEMP 
space allocation. This means that no spooling operations may be 
performed. Thus any data transfer channel program started to a 
virtual unit record output device ends with UC status in the 
virtual CSH and the intervention required bit set in the virtual 
sense byte. 
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SYSRES Macro 



SYSRES MACRO 



Use the SYSRES macro instruction to describe the characteristics of the 
CP system residence volume. 



The name field 
instruction. 



must not be specified for the SYSRES macro 



Sfiecial Considerations for Coding the SYSRES Macro: The following 
information should help you when you code the SYSRES macro: 

• The cylinders required for SYSNOC, SYSEHR, and SYSWRM must be 
formatted using the CP FORMAT service program, and must be allocated 
as permanent space on the SYSRES volume, but not in cylinder 0. 

I • VM/370 allows the 2314 or 2319 "alternate tracks" cylinders 200-203, 
I 3340 Model 35 alternate cylinder 348, and 3340 Model 70 alternate 
I cylinders 696-697, to be used for normal data if they are not needed 
to replace defective tracks. 

The format of the SYSRES macro is: 



Hame | Operation | Operands 



SYSRES 



SYSVOL=serial, 
SYSRES=addresj 
SYSTYPE=(23141, 

2319, 

3330 

3340( 

2305, 
SYSNOC=strtcyl, 
SYSERR=cylinder, 
SYSHRM= (strtcyl,cylcount) 



where: 

SYSVOL=serial 

is the volume identification of the system residence disk. The 
vqlume serial number, serial, is a character string with a maximum 
length of 6 characters. 

SYSRES=address 

designates the device address of the DASD to contain the 
newly-generated system. This address is used only when the VM/370 
nucleus is generated and written on the disk. Thereafter, you can 
IPL the system from any addressable disk device. 

The address is a three-digit hexadecimal device address. 

SYSTYPE=/2314 

|2319 

3330 

3340 

2305 

is the device type of the system residence device. 

SYSNUC=strtcyl 

is the number of the real starting cylinder where the CP nucleus 
resides. 
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The cylinder, strtcyl, is a one- to three-digit decimal number. 

normally, a 2314 or 2319 device requires three contiguous 

cylinders, a 2305 or 3340 device requires four contiguous 

cylinders, and a 3330/3333 device requires two contiguous cylinders 

to contain the CP nucleus. 

Systems being generated with the virtual=real option require 
additional space. For information about how much space to allocate 
for virtual=real configurations, see the "Specifying a Virtual=Real 
Machine" section. 

SYSEBR=cylinder 

is the number of the real starting cylinder where error recording 
records are written. Two contiguous cylinders are required for 
error recording. 

The cylinder is a one- to three-digit decimal number. 

r T 
SYSHRM=[ (]strtcyl| ,cylcount|[) ] 

M I 

L J 

is the number of the real starting cylinder, and optionally the 
maximum number of cylinders, to contain the warm start data. 

The strtcyl is a one- to three-digit decimal number designating the 
first real cylinder where CP warm start information is to be 
saved. 

The cylcount value is a one-digit decimal number (1 through 9) that 
defines the maximum number of cylinders to contain warm start data. 
If cylcount is not specified, 1 is the default value. 

The cylcount operand is optional; if included, the strtcyl and 
cylcount operands must be separated by a comma and enclosed in 
parentheses. Parentheses are optional when only the strtcyl 
operand is specified. The following are valid entries for one 
cylinder warm start areas: 

SYSWRM=(202) 
SYSHRM=202 

Dse the following formulas to calculate the number of warm start 
cylinders required. 
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SYSRES Macro 



Device Type | 



Formula 



2314/2319 


1 N=[ 34 ♦ (NSF/40) 


+ 


(NCS/510) + 


((NAU X 4)/50) ] 








32 




3340/2305 


1 N=[ 26 + (NSF/40) 


+ 


(NCS/510) + 


((NAU X 4)/50) ] 








24 




3330 


1 N=[ 59 ♦ (NSF/40) 


+ 


(NCS/510) + 


((NAU X 4)/50) ] 








57 





where : 

N is the number of cylinders required for warm start data. 

NSF is the maximum number of spool files in the system at any 
one time. There are 40 spool file blocks per 4096-byte 
record. 

NSC is the number of cylinders available for spool files. There 
are 510 allocation blocks per 4096-byte record. 

NAU is the maximum number of active users in the system at any 
one time. There are 50 accounting records per 4 096-byte 
record. 



Example : 

The following SYSRES macro defines the system residence volume as the 

2314 volume with a serial number of CPDSK1. During the system 

generation procedure this volume is found at address 230. The VM/370 
system starts at cylinder 198, the error recording area starts at 

cylinder 4, and the warm start storage area is cylinder 202. The format 
of the SYSRES macro is: 



SYSRES SYSVOL=CPDSK1,SYSRES=230,SYSTYPE=2314,SYSNUG=198, 
SYSERR=4,SYSWRM= (202,1) 



X 



MNOTE Messages: 

The following MNOTE messages may be generated by the SYSRES macro 
instruction: 

INVALID DEVICE TYPE FOR SYSRES 

indicates that the argument of the SYSTYPE operand is not 2305, 
2314, 2319, 3330, or 3340. 

SYSVOL NOT IN OWNED LIST 

indicates that the argument of the SYSVOL operand is a volume 
serial number that was not previously specified in the SYSOWN macro 
instruction. This error occurs if the SYSOWN macro instruction 
does not appear in an assembly before the SYSRES macro 
instruction. 
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SYSOPR Macro 



SYSOPR MACRO 



Use the SYSCPR macro instruction to specify the system operator's 
useridy and the userid of the operator who is to receive vm/370 systen 
dumps. The same userid may be specified in both operands. 



The name 
instruction. 



field must not be specified for the SYSOPR macro 



The format of the SYSOPR macro is: 



Name | Operation | Operands 



SYSOPR 



r T 

I S Y S OP E R=0 PE R A TO R | 
|SYSOPER=userid | 

L J 



r 1 

I xS YS D U M P=OP J R ATN S | 
I ,SYSDOMP=userid | 

L J 



where; 

r T 

I J YS OPE Rf OPE RAT OH | 
|SYSOPER=userid | 

L J 

is the userid of the virtual machine to be assigned to the system 
operator. If SYSOPER is not specified, the userid "OPERATOR" is 
used. 

The userid is a character string up to eight characters long. 

r T 

I S Y SDO MP=OPER ATMS | 
|SYSDUMP=userid | 

is the userid of the virtual machine whose spool input receives the 
system dump file after a system restart. If SYSDOMP is not 
specified, the userid "OPERATNS" is used. 

The userid is a character string up to eight characters long. 

Ex am£l e : 

The following SYSOPR macro designates the OP virtual machine as the 
system operator and directs the system dumps to the CPSYS virtual 
machine. 

SYSOPR SYSOPER=OP,SYSDOMP=CPSYS 
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SYSCOR Macro 

SYSCOB MACRO 

Use the SYSCOR Bacro instruction to generate the internal control block 
called the CORTABLE. 

The name field must not be specified for the SYSCOR macro 
instruction. 

The format of the SYSCOR macro is: 



Name | Operation | Operands 



I SYSCOR I RMSIZE=(XXXXXK1 

I I I yyMj 

I I 



whe re : 
RMSIZE=(xxxxxK 



= rxxxxxK ) 

\ yyMJ 



is the amount of real storage available for VM/370. This value 
limits the amount of real storage used by VM/370 if it is less than 
the total amount of real storage available in the real machine. If 
the available real storage is less than this value when VM/370 is 
initialized, a message indicating the amount of storage available 
is displayed at the operator's console. 

The value, xxxxx, is a three- to five-digit number that denotes the 
amount of real storage in terms of K bytes, where 1K=1024 bytes. 
This value may range from 2'40K to 16384K. It must always be a 
multiple of 2. 

The value, yy, is a one- or two-digit number that denotes the 
amount of storage in terms of M bytes, where 1M=1024K bytes. This 
value may range from 1M to 16M. 

Note: Do not specify a value substantially larger than the size of 
real storage, because the core table generated uses a large amount 
of real storage. 

Exa m^le s : 

The first example defines real storage as 256K (272,144) bytes and the 
second example defines real storage as 1M (1,048,576) bytes. 

SYSCOR RMSIZE=256K 
SYSCOR RMSIZE=1M 

MNOTE Messages: 

The following MNOTE messages may be generated by the SYSCOR macro 
instruction: 

INVALID RMSIZE SPECIFIED 

indicates that the real machine size specified is less than 240K, 
greater than 16M, or not a multiple of 2K . 
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SYSTIME Macro 



SYSTIME MACRO 



Ose the SYSTIME macro instruction to generate information needed to set 
the hardware time of day (TOD) clock. The value stored in the TOD clock 
represents time taken at Greenwich Mean Time, and must be corrected to 
local time whenever it is examined. The system operator can alter the 
defined time value by using the store clock function. 

The name field must not be specified for the SYSTIME macro 
instruction. 

The format of the SYSTIME macro is: 




Operands 



r 1 

ZOHEfO 

ZOME=h 
|ZONE=(h,m) 
|Z01IE= (h,m,s) 
|ZONE=(h,,s) 



^LOCf E AST I 
,LOC=HEST| 

J 



xID=G MT I 
,ID=XXX| 

J 



whe re : 

r T 

I ZO»E= I 

iZONE=h i 

|ZONE=(h,m) I 
|ZONE= (h,m,s) | 

|ZONE=(h,,s) I 

L J 

is the time zone differential from Greenwich Mean Time. If ZONE is 
not specified, a value of hours (Greenwich Mean Time) is used. 

The variable, h, is a number that represents hours. It can have a 
value from to 13, but when coupled with the m and s fields, the 
total effective zone differential must not exceed 13 hours. 

The variable, m , is a number that represents minutes. 

The variable, s, is a number that represents seconds. 

r 1 

ILOCfEASTI 
|LOC=HEST| 

L J 

specifies whether the time zone differential is to be taken EAST or 
WEST of Greenwich Mean Time. The default value for LOC is EAST. 
When the effective value of ZONE is 0, the setting of LOC is 
meaningless. 
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SYSTIME Macro 



r T 

I IPf 6M T I 
|ID=xxx| 

L J 

is the name of the time zone. The default for ID is GMT. The 
variable, xxx, is a three-character string. 

Ex am£les : 

The following examples show how to code the SYSTIME macro for several 
different time zones. 

SYSTIME Z0NE=5,L0C=WEST,ID=EST (Eastern Standard Time) 

SYSTIME ZOHE='*,LOC=HEST,ID=EDT (Eastern Daylight Time) 

SYSTIME Z0»E=6,L0C=IIEST,ID=CST (Central Standard Time) 

SYSTIME Z0NE=7,L0C=WEST,ID=MST (Mountain Standard Time) 

SYSTIME Z0NE=1,L0C=EAST,ID=SET (Standard European Time) 

SYSTIME Z0!iE=1,L0C=EAST,ID=BST (British Summer Time) 

MHOTE Messages : 

The following MNOTE messages may be generated by the SYSTIME macro 
instruction: 

INVALID LOC SPECIFIED 

indicates that the argument of the LOC operand is not EAST or 
WEST. 

ZONE GREATER THAN 13 HOURS 

indicates that the total value of the hours, minutes, and seconds 
subfields of ZONE is greater than 13 hours. 

ZERO LENGTH ID SPECIFIED 

indicates that a zero length ID is specified. 

INVALID ZONE 

indicates that either the hours subfield of ZONE is missing, or 
more than three subfields are specified. 
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SYSLOCS Macro 



SYSLOCS MACRO 

The SYSLOCS macro instruction is a required macro used to generate 
internal pointer variables: This must be the last macro in the dmksys 
deck. 

This macro is required and must be the last macro in the DMKSYS 
file. 

The name field must not be specified for the SYSLOCS macro 
instruction. No operands are required for the SYSLOCS macro; if one is 
specified, it is ignored. 

The format of the SYSLOCS macro is: 



I 1 

I Hame | Operation | Operands I 

I 1 

I I SYSLOCS I I 



Example : 

An example of the SYSLOCS macro is; 
SYSLOCS 
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Creating Your VM/370 Directory 



The VM/370 directory contains the entries of all potential virtual 
machines that are permitted to log on the VM/370 system. Without the 
proper directory entry, a user cannot log on to VM/370. The entries in 
the directory contain the user identification and password, the virtual 
machine I/O configuration, associated virtual and real addresses, disk 
usage values, virtual CPU storage size, and other options. Each user in 
the directory, except those whose password is NOLOG, must have at least 
one device. Any of the various devices described meet this requirement; 
for example, the device may be a console or a spool device. These 
options are discussed in the directory program control statement 
descriptions. 

The VM/370 directory usually resides on the VM/370 system residence 
disk, and is pointed to by the V0L1 label (cylinder 0, track 0, record 
3) . The VM/370 Directory program (module DMKDIR, invoked by the DIRECT 
command, or run standalone) processes the control statements you prepare 
and writes the VM/370 directory on disk. You already described your 
installation's real configuration when you created the real I/O 
configuration file. Now, you describe the many virtual configurations 
for your installation with the Directory program control statements. 

To create a VM/370 directory, you must: 

• Prepare the Directory program control statements 

• Format and allocate the DASD space to contain the VM/370 directory 

• Execute the Directory program 

At this time, you should prepare the Directory program control 
statements. Later, during the system generation procedure, you must (1) 
format and allocate DASD space for the VM/370 directory and (2) generate 
it. The step-ty-step description of the system generation procedure that 
is in Part 3 of this manual reminds you to create your VM/370 
directory. 



CONSIDERATIONS FOR PREPARING THE DIRECTORY CONTROL STATEMENTS 

First, prepare a directory control statement that defines the device on 
which the VM/370 directory is to be written. This statement (DIRECTORY) 
must be the first control statement in the input to the Directory 
program, and is followed by the sets of statements describing your 
installation's virtual machines. 

Next, prepare Directory program control statements describing each 
virtual machine in your installation. The descriptions contain 
accounting data, options, and virtual machine configurations for each 
virtual machine that appears in the VM/370 directory. Information about 
coding these control statements is found in the section, "The Directory 
Program." Appendix C contains an example of a basic set of VM/370 
directory entries. 

I If you intend to define more than 73 virtual devices for a single 
I virtual machine, be aware that any single request for free storage in 
I excess of 512 doublewords (a full page) causes the VM/370 system to 
I abnormally terminate (abend code PTr607) if the extra storage is not 
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available on a contiguous page. Therefore, two contiguous pages of free 
storage must be available in order to log on a virtual machine with more 
than 73 virtual devices (three contiguous pages for a virtual machine 
with more than 146 virtual devices, and so on) . Contiguous pages of 
free storage are sure to be available only immediately after XPL, before 
other virtual machines have logged on. Therefore, a virtual machine 
with more than 73 devices should be the first to log on after IPL. 

VM/370 does not check for overlapping extents; therefore, you must 
ensure that minidisk extents defined in the VM/370 directory do not 
overlarij 

You must define one or more virtual machines for the operator and 
should define virtual machines for the system analyst or system 
programmer. 

The operator's virtual machines should be atle to control: 

• The VM/370 sessions 

• Allocation of machine resources 

• Spooling activity 

• Online disk areas 

You should also define virtual machines for system analysts that are 
equipped to: 

• Perform system analysis 

• Modify certain VM/370 functions 

and additional virtual machines to update or operate: 

• The CP system 

• The CMS system 

• The RSCS system, if you generate one 

• The hardware 

• Other operating systems that run in the virtual machine environment 

• The Installation Verification Procedure 



SYSTEM SUPPORT VIRTUAL MACHINES 

At system generation time, two additional virtual machines should be 
created beyond those needed by normal users (one each for hardware and 
software support) . The IBM FE Program Systems Representative should be 
consulted when the configurations for these virtual machines are being 
determined. 



M§£^ii§^e Su£port 

The hardware support is for: 

• The CPU, which must be supported in a dedicated environment because 
there is no method currently available that allows concurrent support 
of the CPU, real storage, or channels when executing problem 
programs. 

• The input/output equipment, which can be supported using online test 

(OLT) under OLTSEP. The OLTSEP program can be executed in its own 
virtual machine. 
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Any of the offline testing capabilities of the system devices can be 
used on inactive units while the system is operating. 

To perform online hardware support, a virtual machine must be defined 
in the VM/370 directory for the IBM service representative. The virtual 
machine should have enough virtual storage defined to execute OLTSEP. 
Normally, the service representative reguires that the device being 
tested be dedicated to his virtual machine. (The system operator can 
dedicate devices to a virtual machine by issuing the ATTACH command.) 

Also the virtual machine for hardware support should have the minimum 
configuration reguired to run online tests, and provide access to CMS 
with a read/write minidisk. Privilege class F should be assigned to 
allow the hardware diagnostics to be run, and error recording and 
retrieval facilities to be utilized. 

The hardware service representative's virtual machine should also 
have access to CMS and to the error recording area of the system 
residence volume. An EREP program runs under CMS thus allowing editing 
and printing of all VM/370-recorded machine check and channel check 
errors. 

An example of a virtual machine for hardware support (for a 2314 
system) is: 

USER CE CE 320K IM EFG 
ACCOUNT ACT2 CE 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 2314 014 005 CPV2L0 WR READ WRITE 
LINK MAIHT 194 194 RR 
LINK MAINT 190 190 RR 

Virtual device 191 is a CMS A-disk that is to contain programs 
reguired by the service representative. Input/output units to be tested 
are normally attached to the virtual machine for the duration of the 
test. Privilege class F is provided to allow the service representative 
to specify an intensive error recording mode for a particular device 
being tested, and to examine or clear the system error recording area. 

This directory entry is included in the VM/370 directory provided 
with the starter system. 



Software Su££ort 

The virtual machine for software support should have the minimum 
configuration necessary to create (virtually) problems that occur on the 
real machine. The ECMODE option must be specified in the directory 
OPTION control statement for this machine. You should assign privilege 
class G to the user of this machine. Also, you should assign privilege 
class E if he is to examine real storage addresses, and privilege class 
B if he is to allocate devices. 

An example of a virtual machine for software support (for a 2314 
system) is: 

USER MAINT CPCMS 512K 1M BCEG 
ACCOUNT ACT3 MAINT 
OPTION ECMODE REALTIMER 
CONSOLE 009 3215 

128 VM/370: Planning & System Generation Guide 



SPOOL OOC 25U0 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1103 A 

MDISK 190 2314 035 110 CPV2L0 MR READ 

SDISK 191 2314 019 010 CPV2L0 MR READ 

MDISK 194 2314 145 058 CPV2L0 MR READ 

MDISK 199 2314 034 001 CPV2L0 MR READ 



and, optionally: 



MDISK XXX 2314 000 203 yyyyyy MH 

The last entry is optional and is included so that the user, MAINT, can 
write a CP nucleus directly to the system residence volume. If you 
choose to include this optional statement, replace xxx with the address 
of the system residence volume and yyyyyy with its volume serial 
number. 

This directory entry is included in the Release 2 directory provided 
with the starter system. 



I THE VM/370 DIRECTORY SUPPLIED WITH THE STARTER SYSTEM 



I A control 
I with the: 



statement file for the VM/370 directory program is supplied 



I • 2314 Starter System 
I • 3330 Starter System 
I • 3340 Starter System 

I If the supplied control statement file meets your needs, you can execute 
I the Directory program using the supplied control statements. Otherwise, 
I you can code your own control statements or edit the supplied control 
I statements to produce the file you need for your installation. 
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231U STARTER SYSTEM SUPPLIED DIRECTORY 

The VM/370 Directory prograa control file supplied with the 2314 starter 
system is: 

DIRECTORY XXX 2314 LABEL 

USER OPERATOR OPERATOR 320K 1M AECDEG 
ACCOUNT ACT1 OPERATOR 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 2314 004 010 CPV2L0 «R READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 

USER CE CE 320K 1M EFG 

ACCOUNT ACT2 CE 

CONSOLE 009 3215 

SPOOL OOC 2540 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1403 A 

MDISK 191 2314 014 005 CPV2L0 WR READ WRITE 

LINK MAINT 194 194 RR 

LINK MAINT 190 190 RR 
* 
USER MAINT CPCMS 512K 1M BCEG 

ACCOUNT ACT3 MAINT 

OPTION ECMODE REALTIMER 

CONSOLE 009 3215 

SPOOL OOC 2540 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1403 A 

MDISK 190 2314 035 110 CPV2L0 MR READ 

MDISK 191 2314 019 010 CPV2L0 MR READ 

MDISK 194 2314 145 058 CPV2L0 MR READ 

MDISK 199 2314 034 001 CPV2L0 HR READ 
* 

* 

* MDISK XXX 2314 000 203 YYYYYY MW 

* THE ABOVE OPTIONAL ENTRY IS INCLUDED SO THAT THE ID: MAINT 

* CAN WRITE A CP NUCLEUS DIRECTLY TO THE SYSTEM RESIDENCE VOLUME. 

* XXX AND YYYYYY SHOULD BE CHANGED TO THE ADDRESS AND LABEL OF YOUR 

* SYSTEM RESIDENCE VOLUME AS DEFINED IN YOUR DMKSYS MODULE. 

* THE LEADING • * • IN FRONT OF MDISK SHOULD ALSO BE DELETED. 
* 

***** 

USER IVPM1 IVPASS 320K 16M G 

ACCOUNT ACT4 IVPM 1 

CONSOLE 009 3210 

SPOOL OOC 2540 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1403 A 

MDISK 191 2314 001 001 CPV2L0 WR READ WRITE 

LINK MAINT 194 194 RR 

LINK MAINT 190 190 RR 
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USER IVPM2 IVPASS 320K 1M G 
ACCOUNT ACTS IVPM2 
CONSOLE 009 3210 
SPOOL DOC 25a0 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 
MDISK 191 2314 002 001 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 

* 

USER REM2780 REMOTE 320K 
ACCOUNT ACT6 REM2780 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 



CPV2L0 WR READ WRITE 



SPOOL OOD 2540 


PUNCH A 


SPOOL OOE 1403 


A 


SPOOL 010 2540 


READER A 


SPOOL Oil 2540 


READER A 


MDISK 191 2314 


003 001 CPV2L0 


LINK MAINT 194 


194 RR 


LINK MAINT 190 


190 RR 



HR READ WRITE 



USER ECMODE ECMODE 512K 
ACCOUNT ACT7 ECMODE 
OPTION ECMODE REALTIMER 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 
SPOOL OOE 1403 
MDISK 191 2314 
LINK MAINT 194 
LINK MAINT 190 



1M G 



PUNCH A 




A 






029 


005 


CPV2L0 


194 


RR 




190 


RR 





WR READ WRITE 



3330 STARTER SYSTEM SUPPLIED DIRECTORY 



system is: 






DIRECTORY XXX 3330 LABEL 

* 

USER OPERATOR OPERATOR 320K 1M ABCDEG 
ACCOUNT ACT1 OPERATOR 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 3330 004 007 CPV2L0 WR READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 

USER CE CE 320K 1M EFG 
ACCOUNT ACT2 CE 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 3330 Oil 005 CPV2L0 WR READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 
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DSER MAINT CPCMS 512K 1M BCEG 
ACCOUNT ACT3 BAINT 
OPTION ECMODE REALTIMER 
CONSOLE 009 3215 
SPOOL OOC 25a0 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

HDISK 190 3330 030 076 CPV2L0 MR READ 
MDISK 191 3330 016 007 CPV2L0 HR READ 
MDISK 194 3330 106 044 CPV2L0 HR READ 
MDISK 199 3330 029 001 CPV2L0 WR READ 

* 

MDISK XXX 3330 000 404 YYYYYY MW 

THE ABOVE OPTIONAL ENTRY IS INCLUDED SO THAT THE ID: MAINT 

CAN WRITE A CP NUCLEUS DIRECTLY TO THE SYSTEM RESIDENCE VOLUME. 

XXX AND YYYYYY SHOULD BE CHANGED TO THE ADDRESS AND LABEL OF YOUR 

SYSTEM RESIDENCE VOLUME AS DEFINED IN YOUR DMKSYS MODULE. 

THE LEADING • * ' IN FRONT OF MDISK SHOULD ALSO BE DELETED. 



* 
* 

* 

USER IVPM1 IVPASS 320K 16M G 
ACCOUNT ACT4 IVPM 1 
CONSOLE 009 3210 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 3330 001 001 CPV2L0 WR READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 

USER IVPM2 IVPASS 320K 1M G 
ACCOUNT ACT5 IVPM2 
CONSOLE 009 3210 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 3330 002 001 CPV2L0 WR READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 

USER REM2780 REMOTE 320K 
ACCOUNT ACT6 REM2780 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 
SPOOL 010 2540 READER A 
SPOOL Oil 2540 READER A 

MDISK 191 3330 003 001 CPV2L0 WR READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 
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USER ECMODE ECMODE 512K 1M G 

ACCOUNT ACT7 ECMODE 

OPTION ECMODE BEALTINER 

CONSOLE Q09 3215 

SPOOL OOC 2540 READER A 

SPOOL ODD 2540 PUNCH A 

SPOOL GOE ia03 A 

MDISK 191 3330 023 006 CPV2L0 WR READ WRITE 

LINK MAINT 19U 194 RR 

LINK MAINT 190 190 RR 
* 

* CYLINDERS 150 TO 403 ARE UNUSED AND MAY BE USED FOR 

* ANY OTHER VIRTUAL MINIDISK SPACE. IT CAN ALSO BE 

* USED FOR PAGING, SPOOLING OR T-DSK SPACE. 



I 3340 STARTER SYSTEM SUPPLIED DIRECTORY 

The VM/370 Directory program control statements supplied with the 3340 starter 
system is: 

DIRECTORY XXX 3340 LABEL 
* 

USER OPERATOR OPERATOR 320K 1M ABCDEG 
ACCOUNT ACT1 OPERATOR 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 3340 007 014 CPV2L0 HR READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 

USER CE CE 320K 1M EFG 

ACCOUNT ACT2 CE 

CONSOLE 009 3215 

SPOOL OOC 2540 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1403 A 

MDISK 191 3340 021 006 CPV2L0 WR READ WRITE 

LINK MAINT 194 194 RR 

LINK MAINT 190 190 RR 
* 

USER MAINT CPCMS 512K 16M BCEG 
ACCOUNT ACT3 MAINT 
OPTION ECMODE REALTIMER 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 
MDISK 190 3340 048 
MDISK 191 3340 027 
MDISK 194 3340 251 
MDISK 199 3340 046 



203 


CPV2L0 


MR 


READ 


014 


CPV2L0 


MR 


READ 


098 


CPV2L0 


MR 


READ 


002 


CPV2L0 


WR 


READ 
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* 

***** 

* 

* MDISK XXX 3340 000 348 YYYYYY MH 

* THE ABOVE OPTIONAL ENTRY IS INCLUDED SO THAT THE ID: MAINT 

* CAN WRITE A CP NUCLEUS DIRECTLY TO THE SYSTEM RESIDENCE VOLUME. 

* XXX AND YYYYYY SHOULD BE CHANGED TO THE ADDRESS AND LABEL OF YOUR 

* SYSTEM RESIDENCE VOLUME AS DEFINED IN YOUR DMKSYS MODULE. 

* THE LEADING • * • IN FRONT OF MDISK SHOULD ALSO BE DELETED. 

***** 

USER IVPM1 IVPASS 320K 16M G 

ACCOUNT ACT4 IVPMl 

CONSOLE 009 3210 

SPOOL OOC 2540 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1403 A 

MDISK 191 3340 001 002 CPV2L0 WR READ WRITE 

LINK MAINT 194 194 RR 

LINK MAINT 190 190 RR 
* 

USER IVPM2 IVPASS 320K 1M G 

ACCOUNT ACT5 IVPM2 

CONSOLE 009 3210 

SPOOL OOC 2540 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1403 A 

MDISK 191 3340 003 002 CPV2L0 WR READ WRITE 

LINK MAINT 194 194 RR 

LINK MAINT 190 190 RR 
* 

USER REM2780 REMOTE 320K 

ACCOUNT ACT6 REM2780 

OPTION REALTIMER 

CONSOLE 009 3215 

SPOOL OOC 2540 READER A 

SPOOL OOD 2540 PUNCH A 

SPOOL OOE 1403 A 

SPOOL 010 2540 READER A 

SPOOL Oil 2540 READER A 

MDISK 191 3340 005 002 CPV2L0 WR READ WRITE 

LINK MAINT 194 194 RR 

LINK MAINT 190 190 RR 
* 

USER ECMODE ECMODE 512K 1M G 
ACCOUNT ACT7 ECMODE 
OPTION ECMODE REALTIMER 
CONSOLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 PUNCH A 
SPOOL OOE 1403 A 

MDISK 191 3340 041 005 CPV2L0 WR READ WRITE 
LINK MAINT 194 194 RR 
LINK MAINT 190 190 RR 
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I ALLOCATING DASD SPACE FOB THE VM/370 DIRECTORY 

I Before you create your VB/370 directory using the Directory program, be 

I sure you have enough DASD space allocated as directory space (DECT) * 

I Ose the CP Format service program to format and allocate the cylinders 

I to be used for the VM/370 directory. The cylinders must be allocated as 

I DRCT. To calculate the total number of cylinders required, first 

I calculate the total number of records used: 

I NU ((HO + NM) X 2) ♦ all other control statements 

I NR = + 

I 169 170 

I NR = total number of records used 

I NU = number of USER control statements 

I NH = number of MDISK control statements (except for T-disks) 

I Then, calculate the number of cylinders NC: 

I • For 3330: NC = NR/57 

I • For 2314,2319: NC = NR/32 

I • For 2305,3340: NC = NR/2U 

I Note: You should initially format and allocate space for two VM/370 

I directories. (See the discussion of the Format/Allocate Service 

I Program, DHKFBT, in Appendix F.) You can then build a new directory 

I whenever needed, without overlapping the current one, and without 

I formatting and allocating space each time a new directory is created. If 

I you wish to reallocate the area in which the directory resides, you must 

I reallocate the DASD space and then rerun the Directory program, ihen a 

I VM/370 directory is written, space is allocated from available 

I cylinders, a full cylinder at a time, and a minimum of two cylinders are 

i used for the Vn/370 directory. 

I Once a new VM/370 directory is successfully written, cylinders used 

I for the old directory (marked as temporarily allocated during directory 

I creation) are marked as free. In this way, DASD space allocated for DRCT 

I cylinders is freed and can be reused for the next directory creation. If 

I space for two directories is not initially allocated, each time you want 

I to create a new directory, you must allocate space for the directory 

I before you create it. 
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Directory Program 

I THE DIRECTORY PROGRAM 

The VM/370 Directory service program can be run under CMS (using the 
DIRECT command) or standalone. The standalone version of the Directory 
program is provided in object deck form (a three card loader, followed 
by the DMKDIR text deck) , and may be loaded directly from either a real 
or virtual card reader. 

If you run the Directory program under CMS, input records must be in 
a CMS file with a default fileid of "USER DIRECT". The DIRECT command 
loads the directory creation module. If no filename is specified, the 
program looks for a file named USER DIRECT. Otherwise, it looks for a 
file named filename DIRECT. 

If the file is not found, or if an error occurs during processing, 
the directory is not created and the old directory remains unaltered. 

Normal completion writes the DASD address of the new VM/370 directory 
in the V0L1 label, and if it is updating the active system directory, it 
places the new directory in use by VM/370. You can print the new 
directory by issuing the CMS command PRINT USER DIRECT (or PRINT 
filename DIRECT) . 

The virtual machine executing the Directory program must have write 
access to the volume to contain the new directory. If you create a 
directory that is to be written on the active VM/370 system residence 
volume, your virtual machine's current directory entry must have write 
access to the volume containing the current VM/370 directory. 

Example: Assume that you have the following virtual machine for online 
directory modification. 

USER OPERATNS PASSWORD 256K 1M ABC 
ACCOUNT NUMBER BIN2 
IPL CMS 

CONSOLE 009 3215 
SPOOL C 2540 READER A 
SPOOL D 2540 PUNCH A 
SPOOL E 1403 A 
LINK CMSSYS 190 190 R 

MDISK 330 3330 404 SYSRES WR RPASS MPASS 
MDISK 331 3330 404 SYSWRK WR RPASS WPASS 
MDISK 230 2314 203 UDISK1 RR RPASS WPASS 
MDISK 231 2314 203 UDISK2 RR RPASS WPASS 
MDISK 232 2314 203 BATCH1 RR RPASS WPASS 
MDISK 233 2314 203 BATCH2 RR RPASS WPASS 
MDISK 191 3330 26 010 VMDSK2 WR RPASS WPASS 

Using the CMS EDIT command and its subcommands, you can create or 
modify a card-image file of the VM/370 directory input. When you are 
ready to write a new directory, issue the command: 

DIRECT filename 

where filename is a CMS file (normally named USER) with filetype DIRECT 
containing the necessary Directory program control statements. The 
DIRECT command puts this file into the form of a directory, and replaces 
the old directory with this new one. 

Loading the DMKDIR object deck via the card reader is the same as 
issuing the DIRECT command in CMS, except that after IPL, the program 
asks you for the address of a card reader containing the Directory 
program control statements. 
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Directory Program 

I Once the directory is updated, directory changes for a user currently 
I logged on to the system do not take effect until the user logs off the 
I system and then logs back on. 

i Hhen a new directory is vritten for a new s'^stes residence volume - 
I the new directory does not take effect until the new system residence 
I volume is loaded (via IPL) . 



j INVOKING THE DIRECTORY PROGRAM (DMKDIR) UNDER CMS 

I The VM/370 Directory service program records the configuration of each 
I user's virtual machine in the VM/370 directory. Each virtual machine 
I configuration includes counterparts of the components found in a real 
I System/STO: a virtual operator's console, virtual storage, and virtual 
I I/O devices and control units. 

I The same version of the Directory service program deck may be placed 
I in the card reader and loaded directly, or run in a virtual machine 
I under CMS. For system generation, the standalone facility must be 
I used. 

I The CMS file named DIRECT may be updated with the CMS Editor to 
I include additional directory entries. 



The CMS DIRECT Command 

Use the CMS DIRECT command to process any file to see if it follows the 
required directory format. To actually change or swap the currently 
active VM/370 directory, you must have both of the following: 

1. User class A, B, or C. 

2. Write access to the system-owned (system residence or IPL device) 
volume that contains the current directory up to and including the 
directory cylinders, or to the voxUiDe that is to contain the new 
directory. 

If you have the above qualifications and wish to verify that a CMS 
file can be used as a directory file, you must use the EDIT option; 
otherwise, if there are no control statement errors, the file is put 
into active use. 

To build a VM/370 directory on a CP-owned volume using preallocated 
cylinders, a new directory should be built so as not to overlay an 
existing directory. You must therefore allow space for two directories, 
or allocate a new area for the VM/370 directory each time it is 
created. 

If you execute the Directory Program under VM/370, the newly created 
directory is dynamically swapped, and placed in use by VM/370 (provided 
that you have class A, B or C and that the directory volume is a 
system-owned volume) . Whether or not you have the proper privilege class 
the directory is updated on the directory volume. The format of the 
DIRECT command is: 
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II r T 

I DIRECT I [filename [filetype |filemode|]] [(EDIT)] 

I I L * J 



w her e : 

filename [filetype [filemode]] 

is the identification of the file containing the control 
statements for the Directory Program. If no filename and 
filetype are given, the program defaults to a file named 'OSER 
DIRECT;* otherwise, it looks for the file named. The filetype 
must be DIRECT. The filemode defaults to * if not specified. 

(EDIT specifies that the directory is to be examined, but not 
changed. 

Under CMS, the DIRECT command loads the directory creation module. 
The first statement encountered must be a DIRECTORY statement. If not 
found, or another DIRECTORY statement is found, the program terminates. 

A syntax error in any statement generates an error message, and the 
directory is not updated. If no critical errors are encountered, the 
remaining statements are checked for syntax. 

If the Directory program abnornally terminates, the old directory is 
not altered. Normal completion places the directory in use by VM/370. 
After the new directory is created, it can be printed by issuing the CMS 
command PRIMT USER DIRECT or PRINT filename DIRECT. 

The DIRECT command filename and filetype default to a CMS file 
identification of USER DIRECT. The filemode defaults to * if not 
specified. Any or all of the defaults can be overridden by the command 
line. The EDIT option allows you to run the program without updating 
the directory on disk. This enables you to check the syntax of the 
directory statements without accessing the directory disk. 



INVOKING DIRECTORY AS A STANDALONE PROGRAM 

Standalone operation is the same as CMS operation, with this exception: 
after IPL, the program asks you for the virtual card reader address. If 
you enter a null line, the IPL device address is the default of OOC. 

DIRECTORY CONTROL STATEMENTS 

The control statements should be in the following formats, with one or 
more blanks as operand delimiters. All operands are positional from 
left to right. If any operands are omitted, all remaining operands in 
that statement must be omitted, with the exception of the OPTION 
statement. Its entries are self-defining and not positional. 

Only columns 1 through 71 are inspected by the program. All data 
after the last possible operand on any card is ignored. Also, blank 
cards and cards having an asterisk (*) as the first operand are 
ignored. 

If any input card is found to be in error, the program continues to 
process the control statements, validating all control statements before 
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terminating. If the directory runs out of space, the program terminates 
immediately. After an abnormal termination (or, for CMS, the EDIT run), 
the old directory is not altered, and the new directory is not saved. 



I PIIICTORY Control Statement 

The DIRECTORY control statement defines the device on which the 
directory is allocated. It must be the first statement. The format of 
the DIRECTORY control statement is: 

1 1 

I DIRectory cuu devtype volser | 

I 1 

where : 

cuu is the input device address, specified in 3 hexadecimal 
digits. 

devtype is four decimal digits that represent a supported device type 
suitable for the VM/370 directory (2314, 2319, 2305, 3330, or 
3340). 

volser is the volume serial number of the directory volume (one to 
six alphameric characters) . 



I USER Control Statement 

I The USER control statement defines a virtual machine and creates a 
I VM/370 directory entry. It delimits the directory entry for one user. A 
I separate USER statement must be prepared for each directory entry 
I required. The format of the USER control statement is: 

I 1 

r r r r T "m ! 
User userid pass [stor [ mstor [cl [ pri |le |ld |cd |es Mil]]]] I 

|0M ION jON jON Mil I 
|OFF lOFF |OFF lOFF Mil I 

L L L L JJJJ I 

I 1 

w her e : 

userid is a one- to eight-character user identification. Any 
alphameric characters may be used except SYSTEM. SYSTEM is 
the userid of the VM/370 system VMBLOK, and should never be 
used for a virtual machine. Each user in the directory, 
except for those whose password is UOLOG, must have at least 
one device. Any of the various devices described meet this 
requirement; for example, the device may be a console or spool 
device. 

Motes: 
1. The userid should not contain the characters "LOGONxxx", 
where xxx is a terminal address of the installation. This 
character string is assigned to the terminal at address 
xxx from the time the initial interrupt is received until 
the user is identified, during log on. 
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2. Do not specify SYSTEM as a userid. VM/370 reserves SYSTEM 
as an identifier for its own use. 

pass is a one- to eight-character user security password that must 
be entered by the user to gain access to the VM/370 system and 
the virtual machine you are defining in these control 
statements. 

Note: Do not use the password NOLOG as it is reserved for 
users who do not have a virtual machine configuration in the 
VB/370 directory. NOLOG is used for spooling purposes only; 
attempts to log on using this password are inhibited. 

stor is one to eight decimal digits- that define the virtual 
machine's storage size. It must be a multiple of 4K. The 
last character must be K or M. The default is 128K. The 
minimum size is 8K. All entries not on a UK boundary are 
rounded up to the next UK boundary. The maximum size is 16M. 

mstor is one to eight decimal digits that define the maximum virtual 
machine storage size that this user can define as his storage 
after logging on the system. It must be coded in multiples of 
4K. The last digit must be K or M. The default size is 1M. 
All entries not on a 4K boundary are rounded to the next 4K 
boundary. The minimum size is 8K. The maximum size that can 
be specified is 16M. 

cl is one to eight characters from A to H (with no intervening 
blanks) defining the privilege class or classes given to this 
user. The default is G. 

Note: If privilege class F is assigned to a virtual machine, 

I/O error recording is not automatically done. This allows 

the class F user to set the kind of error recording he wants 
to perform. 

pri is a number from 1 to 99 used by the control program priority 
dispatcher. One is the highest priority and fifty is the 
default. 

Note: The same priority value can be used for several users. 
Also, if the specification for this statement is not entered, 
then line end (le) , line delete (Id) , character delete (cd) , 
and escape (es) characters default to system— defined values. 

The following special VM/370 logical editing symbols may be set ON, 
OFF, or substituted with two hexadecimal characters or one graphic 
character of the user's choice. 

Mote: In addition to the directory specification, the user can change 
these logical editing symbols using the TERMINAL command. The default 
value for all symbols is ON. 

le is a one— character "line end" symbol or a two— character 
hexadecimal representation of the symbol. ON sets the system 
default value (#) . OFF disallows "line end" symbol usage. For 
example: 

"le" can be coded as + or 4D or ON or OFF. 

Id is a one— character "line delete" symbol or a two-character 
hexadecimal representation of the symbol. ON sets the system 
default {0) . OFF disallows "line delete" usage. 
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cd is a one-character "character delete" symbol or a 
two— character hexadeciuial representation of the symbol. ON 
sets the system default value (3) . OFF disallows "character 
delete" usage. 

es is a one-character "escape-character" symbol or a 
two-character hexadecimal representation of the symbol. ON 
sets the system default (") . OFF disallows "escape character" 
symbol usage. 



ASiSiOOfil' S;2fii£2i statement 

The ACCOUNT control statement defines an account number and a 
distribution identification. The distribution identification has no 
internal system use; it is provided for customer use (for example, a 
code for distribution of printed output) . The ACCOUNT statement is 
optional. This statement (if coded) must follow the USER statement and 
precede the first device statement. The format of the ACCOUNT control 
statement is: 



I Account number [distribution] 

I 



w h er e : 

number is a one— to eight— character account number that is 
punched in the accounting data for this virtual machine. 
The USEEID from the USER statement is also punched in the 
accounting data. 

distribution is a one- to eight-character distribution identification 
word that is printed or punched with the userid in the 
separator for spooled output for this user. This value is 
optional and defaults to the userid from the USER 
statement if omitted. 



OPTION Control Statement 

The OPTION control statement selects specific options available to the 
user. This statement is optional and, if used, must follow the USER 
statement and precede the first device statement (CONSOLE, MDISK, 
DEDICATE, LINK, or SPOOL). The format of the OPTION control statement 
is : 



I 1 

I Option Realtimer Ecmode Isam Virt=real Acct Svcoff BMX | 

I 1 



where : 

REALTIMER provides a timer for the virtual machine that is updated 
during virtual CPU run time and also during virtual wait 
time. (If the virtual machine does not have the 
REALTIMER option, its timer reflects only the virtual CPU 
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run time used.) This option is required for RSCS and for 
virtual machines running systems or programs that go into 
a wait state expecting a timer interruption. This timing 
ability can also be obtained by issuing the CP command 
line SET TIMER BEAL. 

ECHODE allows the virtual machine to run in extended control 
mode. The ECMODE option must be specified for virtual 
machines using operating systems that: 

1. Operate in System/370 extended control mode (such as 
VM/370 itself) . 

2. Use the dynamic address translation facility (such 
as 0S/VS1, 0S/VS2 and VM/370). 

3. Ose extended control registers other than zero (such 
as OS GTF [General Trace Facility], which uses 
Monitor Call and requires extended control register 
eight) . 

4. Depend on the System/370 extended channel masking 
feature. 

The ECMODE option must also be specified for the 
virtual machine that is to perform system support or 
updating. 

A virtual machine defined without the ECMODE option in 
the directory is limited to six I/O channels, while a 
virtual machine with the ECMODE option may address up to 
16 I/O channels. If a virtual machine with the ECMODE 
option executes in basic control mode, the I/O masking 
for channels 6 and higher is simulated by the extended 
channel feature. If a virtual machine with the ECMODE 
option executes in extended control mode, the I/O masking 
for all sixteen channels is handled via extended control 
register 2. 

! This facility can also be obtained by issuing the CP 

I command line SET ECMODE ON. 

ISAM provides special channel command word translation 

routines that permit OS/PCP, MFT, and MVT ISAM programs 
(which dynamically modify their CCWs) to operate properly 
in a virtual machine. This is required only for virtual 
machines that use OS/PCP, MFT, or MVT ISAM access methods 
or VS1 ISAM when executing in a V=R partition under VS1. 
This option is not needed for DOS, DOS/VS, or OSVSl ISAM 
when run only in a V=V partition of VSl. 

I This facility can also be obtained by issuing the CP 

I command line SET ISAM ON. 

VIRT=REAL is a performance option that allows the user to place his 
virtual machine in lower storage, such that its virtual 
storage addresses correspond to the real storage address 
(except for its page zero, which is relocated) . The real 
page zero is controlled by the CP nucleus. No CCH 
translation is required. This option is required for a 
virtual machine to successfully execute self-modifying 
channel programs other than those generated by OS/VS TCAM 
(Level 5, generated or invoked with the VM/370 option) or 
OS ISAM. VIRT=REAL can be specified for any number of 
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virtual machines but only one virtual machine can use 
this facility at any given time. 

To generate a ?M/370 system with a virtual=real machine, 
see the "Specifying a Virtual=Real Machine" section of 
Part 1. 
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ACCT a user with the ACCT option in his directory can charge 

another user for virtual machine resources. For example, 
a user who sends a job to the CMS batch virtual machine 
can be charged for the time that he uses in the batch 
machine = 

SVCOFF specifies that CP, instead of the Virtual Machine Assist 
feature, handles all SVC interrupts for this virtual 
machine. A user whose directory entry contains this 
option can override it by issuing SET ASSIST SVC. 

Note: All SVC 76 interrupts are handled by CP whether or 
not the SVCOFF option is specified. 

BMX specifies that all virtual machine I/O operations are to 

occur as block multiplexer channel operations rather than 

multiplexer mode, the virtual channel is not busy until 
the initial SIO is complete (selector mode operates 
similarly) . Block multiplexer allows the successful 
start of multiple SIOs to different devices on the same 
channel. However, virtual I/O operations on channel 
are processed as byte multiplexer channel operations. 
Channels that have a channel-to-channel adapter are 
restricted to selector channel operation. 

Note: The channel mode setting can be changed by use of 
the CP DEFINE command. 



I lEL Control Statement 

The IPL control statement contains a one- to eight-character name of the 
system (or one- to three-digit I/O device address) to be loaded for the 
user when he logs on. This statement is optional; if specified, it must 
follow the USER statement, and must precede the first device statement 
(CONSOLE, MDISK, or SPOOL) . The IPL statement can be overridden by the 
user at logon time by specifying "LOGON userid NOIPL". ( Note: If the 

I .-> ^ »'^ i r^ 4. U <^ ^-^Atm-^-^-r, r-.'Twr^*.^^ ^ -^ ^ -^ "^ 4. ^ -^ -> n -^ x-, 4- ^ m -^ *■ i ^ XDT Ar^ n ^ 4- r\ n f ■(: n r-m r\fi 

I uo CI. J.O cue ^i. J.IUCIX. jr ojro«.cui u^cj.auv^i., au au cv-fuia v. j.«^ j.cxi u.o £>^^ pc i. j. u j. uicu 

I when he logs on.) The format of the IPL statement is: 



1 

I Ipl iplsys I 



w h er e : 

I iplsys is a one- to eight-character system name or the virtual 
I address of the device containing the system to be loaded. 
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I CONSOLE Control Statement 

The CONSOLE control statement specifies the virtual console. The format 
of the CONSOLE control statement is: 



« 1 

I Console cuu devtype [class] I 

• 1 

w h er e : 

cuu is the virtual device address of one to three hexadecimal 
digits. 

devtype is the device type: 
1052 
3210 
3215 

I ]io^§« The system accepts any of the devtypes indicated 

I regardless of the real console or terminal being used. Device 

I types 3277, 3066, 3158, 27U1, and 3767 cannot be specified. 

I Only one console can be specified. If a different console is 

! sometimes reguired, use the CP DEFINE command to change the 

I console address or add an alternate console. 

class is a one character spooling class. A through Z and through 
9 are valid. The class governs the printing of the real 
I spooled output. If the class operand is omitted, the default 

I is class T and is for console spooling. 



MDISK Control Statement 

I The MDISK control statement describes the cylinder extent on a direct 

I access device to be owned by the user. The DASD area assigned with this 

! statement beconies the user's minidisk. The format of the MDISK control 
statement is: 



r 
I I 
I I 



Mdisk cuu devtype Tcylr cyls volser [mode [ pr [ pw [pm]]]]) 

\ T-disk cyls j 



where : 

cuu is the virtual device address of one to three hexadecimal 
digits. 

devtype is the device type: 
2305 

2311 Top (Top half of a 231U or 2319) 
2311 Bottom (Bottom half of a 2314 or 2319) 
2314 
2319 
3330 
3340 

fcylr 1 is a three-digit decimal cylinder relocation factor which 

\ T-disk / specifies the cylinder on a real disk that corresponds to 

cylinder of the virtual disk. If T— disk is specified, 
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temporary disk space is obtained at logon time from 
preallocated system disk space. This space must be initialized 
or formatted by the user when he logs on and is a part of his 
virtual configuration until he logs off or detaches the disk, 
at which time the data area is returned for reallocation for 
another T-DISK area. To maintain security this area should be 
physically erased before it is returned. 

Bote: It is not advisable to define that a minidisk start at 
real cylinder zero (unless the minidisk is to be used by OS 
ISAM, in which case it must begin at real cylinder zero) . If 
you do assign a minidisk beginning at real cylinder zero, the 
uset who owns it must realize that the minidisk label is the 
real label that both he and the VM/370 system use to identify 
the disk. Also note that CP-owned volumes must not have 
minidisks beginning at real cylinder zero. 

cyls is a one- to three-digit decimal number specifying the number 
of cylinders. The maximum number of cylinders that can be 
specified for a minidisk is 203 cylinders on a 2314, U04 
cylinders on a 3330 Model 1 or 2, 808 cylinders on a 3330 
Model 11, 349 cylinders on a 3340 with data module 35, and 698 
cylinders on a 3340 with Data Module 70. The maximum number of 
cylinders supported by CMS for a single minidisk is 246 on a 
3330 device and 682 on a 3340 device. 

volser is the volume serial number of the DASD volume (one to six 
alphameric characters) . 

mode is the primary access mode reguested for the device 
(read— only, write, or multiple-write) , and the alternate 
access (read-only or write) desired (if any), as follows: 

H specifies that read-only (R/0) access is reguested. The 
access is not given if any other user has the disk in 
write status. 

RR specifies that read-only access is reguested, even if 
another user has the disk in write status. 

W specifies that write access is reguested. The disk is 
not defined if any other user has the disk in read or 
write status. 

WH specifies that write access is reguested if no other 

user has the disk in read or write status, but that an 

alternate access of read-only is acceptable if others do 
have a link to the disk. 

M specifies that multiple access is reguested. This means 
that a write link is to be given to the disk unless 
another user already has write access to it, in which 
case no link is to be given. 

MR specifies that a write link is to be given to the disk 
unless another user already has write access to it. In 
this case, a read link is given to the user and the 'DEV 
xxxx FORCED R/0' message is issued. 

MH specifies that a write link is to be given to the disk 
in any case. 

If a mode specification is omitted from the statement, it 
defaults to W. 



Part 2: Defining Your VM/370 System 145 



GC20-1801-4, Page Modified by GN20-2658, March 31, 1975 
Directory Progran 

pr is the password that allows sharing in read mode (a one- to 
eight-character field) . 

pw is the password that allows sharing in write mode (a one- to 
eight-character field) . 

pm is the password that allows sharing in multiple-write mode (a 
one- to eight-character field) . 

A write password (pw) cannot be specified without a read password (pr) ; 
a multiple-write password (pm) cannot be specified without both a read 
password (pr) and a write password (pw) . 

Note: If a password of ALL is used for pr, pw, or pm, a user other than 
the owner of the minidisk is allowed to link to this minidisk without 
specifying a password. 

Ex am£l es : 

MDISK 230 3330 5 10 HORK01 W ALL WRITE 

is an MDISK statement for a minidisk with read/write access to 10 
cylinders located on a real 3330 disk volume labeled HORK01, 
beginning at real cylinder 5. A user other than the owner of this 
minidisk can link to it in read status without specifying a read 
password, but must specify a password of 'WRITE' in order to gain 
write access to it. 

MDISK 191 2314 50 15 CPDSKU W RDPASS WRX2* 

is an MDISK statement for a minidisk with read/write access to 15 
cylinders located on a real 2314 labeled CPDSK4 starting at cylinder 
50. A read password of RDPASS and a write password of WRX2* are 
provided. This allows the other users to access the minidisk through 
the directory LINK statement (see the description of the LINK 
statement in this section) or the LINK command. 



Sj^OOi! Control Statement 

The SPOOL control statement specifies the unit record device that is to 
be spooled. Multiple readers, punches, and printers may be specified, 
each on a separate SPOOL card. The format of the SPOOL control 
statement is: 

I 1 

I Spool cuu devtype [class] I 

i_^ 1 

where : 

cuu is the virtual device address (one to three hexadecimal 
digits) . 

devtype is the device type: 

1403 

2501 

1443 

3211 
I 2540 R[EADER] 

I 2540 pfuNCH] 

3525 

3505 
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class is a one-character spooling class. A through Z, through 9, 
or * is valid. For spool output devices, the class governs 
the punching or printing of the real spooled output. If this 
operand is omitted, the default class A is used. This operand 
is reguired for all output devices defined on the spool 
record. For spool input devices, the class controls access to 
spool files by virtual card readers. The default class for 
readers is an asterisk (*) , which means the reader can process 
any class of spool file. 

For example: 

SPOOL OOE 1403 A 

specifies a SPOOL record for a virtual 1403 at address OOE. 
The output class is A. 



DEDICATE Control Statement 

The DEDICATE control statement specifies that a real device is to be 
dedicated to this user. If the device is a unit record device, input 
and output are not spooled by VM/370. A real device may be dedicated to 
only one user at a time. Should a device be specified as dedicated in 
more than one directory entry, only the first user to log on gains 
access to it. The format of the DEDICATE control statement is: 



I 1 

I I Dedicate cuu { rdev |[VOLID] volser } [R/0] | 

I 1 



whe re : 

cuu is the virtual device address (one to three hexadecimal 
digits) . 

rdev is the real device address (one to three hexadecimal digits) . 

VOLID volser 

is an optional keyword used if the volser is less than four 
characters long. It is optional if volser is four, five, or 
six characters long. 

The variable, volser, is the volume serial number of a disk 
pack mounted on some real disk storage device (one to six 
alphameric characters) . 

If the VOLID operand is used, the volume must be attached to 
the system when ' the user logs on. Hhen he legs off, the 
operator can then detach the volume from the system. 

I R/0 specifies that the virtual device is to be in read-only 
I status. If this operand is omitted, the status defaults to 

I read/write. 
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Exa Bfles : 

DEDICATE 0B8 OBO 

is a DEDICATE statement for a device at real address OBO. Its 
virtual address is OBB. 

DEDICATE 250 MYPACK 

is a DEDICATE statement that defines, for this virtual machine, 
virtual address 250 as the real device where DASD volume MYPACK is 
mounted. 



hIM Control Statement 

The LINK control statement makes a device that belongs to another user 
(userid) available to this virtual machine at logon time. If you want 
to make one volume available to several virtual machines: 

• Define the volume for one of the virtual machines with an MDISK 

• Define a link to that volume, with the LINK statement for all other 
virtual machines that use the volume. 

Then, if you later must move or change that volume you only need to 
update the one MDISK statement, the LINK statements need not be 
updated. The format of the LINK control statement is: 



I 1 

I Link userid Idev [ cuu [mode]] I 



w her e : 

userid is the one— to eight— character user identification of the user 
to be linked to. 

Idev is the virtual device address of the device owned by userid to 
be linked to (three hexadecimal digits) . This is the virtual 
device address, assigned by userid, of the disk you wish to 
link to. 

cuu is the virtual device address for the virtual machine being 
defined, "cuu" defaults to the same address as the linked-to 
device (three hexadecimal digits) . If your virtual machine 
has the ECMODE option, any address up to X'FFF* is valid; 
otherwise, any address up to X'SFF* is valid. 

mode is the primary access mode requested for the device 
(read— only, write, or multiple-write) , and the alternate 
access (read-only or write) desired, if any, as follows: 

R specifies that read-only (R/0) access is requested. The 
link is not given if any other user has the disk in 
write status. 

BR specifies that read-only access is requested, even if 
another user has the disk in write status. 
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H specifies that write access is requested. The disk is 
not defined if any other user has the disk in read or 
write status. 

WR specifies that write access is requested if no other 

user has the disk in read or write status, but that an 

alternate access of read-only is acceptable if others do 
have a link to the disk. 

M specifies that multiple access is requested. This means 
that a write link is to be given to the disk unless 
another user already has write access to it, in which 
case no link is to be given, 

MR specifies that a write link is to be given to the disk 
unless another user already has write access to it. In 
this case, a read link is to be given to the user, and 
the 'DEV xxxx FORCED R/0' message is issued. 

MW specifies that a write link is to be given to the disk 
in any case. 

Note: If the mode is not specified, the default is R. 

It is the responsibility of the operating system executing in each 
virtual machine to keep data from being destroyed or altered on shared 
disks. 

CHS supports multiply-accessed read-only disks in full. CHS does not 
support write access to disks by multiple users. A disk accessed in 
write mode by one CMS user is available to other CMS users in read-only 
mode, but those files altered by the write-mode user cannot be read by 
the other users. 

CHS disks should never be linked in write mode to more than one 
user. If two or more CMS users have write access to the same disk, all 
data on the disk may be destroyed. 



SPECIAL Control Statement 

The SPECIAL control statement specifies the I/O units available to the 
user that need not have a real I/O unit available. Special devices are 
program simulated devices that may or may not be connected to real or 
virtual devices after the user has logged off. The format of the 
SPECIAL control statement is: 



r- 



I SPEcial cuu devtype [IBM|Tele] I 

L I 
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GC20-1801-a, Page Hodified by GIJ20-2658, Harch 31, 1975 
Directory Prograa 

w h er e : 

cuu is a one- to three-character virtual device address. 

devtype is the device type: 

2701 

2702 

2703 

3158 (virtual 3158 console) 

3270 (virtual 3270 only) 

CTCA (channel to channel adapter) 

(The virtual address must be a control unit address — 
last four bits set to zero — resulting in 16 device 
addresses being defined.) 

TIHEB (pseduo-timer device) 

IBM valid only if devtype is 2701, 2702, or 2703 
TELE 

For example, a virtual machine executing a multiple-access system that 
supports four IBH Type 1 adapter lines, would have four SPECIAL entries, 
one for each of those addresses. This provides a virtual 270X line to 
allow a user to dial to this multiple-access system rather than logging 
on as a separate virtual machine. 

Notes : 

1. The Integrated Communications Attachment (ICA) on the System/370 
Model 135 should be specified as a 2701. 

2. The 3270 is only supported by ?M/370 as a locally attached device. 
It is not supported as a remote terminal on leased or switched 
lines. 
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Preparing the System Name Table File (DMKSNT) 



The system name table consists of entries that identify the name and 
location of saved systems. Two macros generate entries for the system 
name table: 

• The NAMESYS macro creates an entry in the system name table for a 
virtual machine operating system. 

• The NAMENCP macro creates an entry in the system name table for a 
3704/3705 control program. 

A system name table is supplied for each starter system. The DMKSNT 
module supplied with the 231U starter system is: 

DMKSNTBL CSECT 

CMS NAMESYS SYSSIZE=256K, SYSNAME=CMS, X 

VSYSADR=190,SYSVOL=VMREL2,SYSCYL = 035,SYSSTRT= (001,1) , X 
SYSPGCT = 35,SYSPGNM= (0-34) ,SYSHRSG=1 , VSYSRES=CPV2L0 
END 

The DMKSNT module supplied for the 3330 starter system is: 

DMKSNTBL CSECT 

CMS NAMESYS SYSSIZE=256K, SYSNAME=CMS, X 

VSYSADR=190,SYSVOL=VMREL2,SYSCYL=030,SYSSTRT=(001,1) , X 
SYSPGCT=35,SYSPGNM=(0-34) ,SYSHRSG=1 ,VSYSRES=CPV2L0 
END 

The DMKSNT module supplied for the 3340 starter system is: 

DMKSNTBL CSECT 

CMS NAMESYS SYSSIZE=256K, SYSNAME=CMS, X 

VSYSADR=190,SYSvOL=VMREL2r SYSCYL = 048, SYSSTRT= (001 , 1) , X 
SYSPGCT=35,SYSPGNM= (0-34) ,SYSHRSG=1 , VSYSRES=CPV2L0 
END 

The supplied DMKSNT modules each have only one entry: an entry that 
can save a copy of CMS if you use all the recommended labels and 
allocations and the starter system supplied DMKSYS when you follow the 
system generation procedure. If you wish to change or add to the system 
name table that is supplied, you must code your own macro and create a 
DMKSNT file of your own. The system generation procedure tells you when 
to assemble your own file. If the supplied DMKSNT module meets your 
installation's needs, you do not have to code or assemble the DMKSNT 
module. 

If you do create your own version of the system name table, your file 
must have a CSECT and END statement: 

DMKSNTBL CSECT 

NAMESYS macros (one for each virtual machine operating 

system you wish to save) 
NAMENCP macros (one for each 3704/3705 control program 

you create) 
END 
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I Information about coding the HAHESYS and NAHENCP macros follows. 

I Note that the supplied module contains a POUCH SPB (Set Page 

I Boundary) card, which is used by the loader to force this module to a 4K 

I boundary when the CP system is built. A 12-2-9 multipunch must be 

I specified in column 1 of an SPB card. Be sure that the SPB card is not 

I deleted. 
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COpiMG THE NAHESYS MACRO 

The HAMESYS lacro describes the location of the saved system. Shared 
segments may be specified; but they must consist of reenterable code, 
with no alteration of its storage space permitted. 

The format of the NAMESYS macro is: 

r 1 

label I NAMESYS | SYSSIZE=nnnK ,SYSNAME=name, VSYSRES=cccccc, 
I I VSYSADR=cuu,SYSVOL=cccccc,SYSCYL=nnn, 

I I SYSSTRT= (cc,p) ,SYSPGCT=ppr 

I I SYSPGNM= (nn,nn,nn-nn,. . .) » 
I I SYSHRSG= (s,s,...) 



where : 

label is any desired user label. 

SYSSIZE=nnnK 

is up to three decimal digits representing the amount of 
storage you must have available in order to IPL the saved 
system. K must be specified. 

SYSNAME=name 

is the name (up to six alphameric characters) given to the 
system to be used for identification by the SAVESYS and IPL 
commands. The name selected must never be one that could be 
interpreted as a hexadecimal device address (for example, 'A* 
or 'E') . 

VSYSRES=CCCCCC 

is the real volume serial number (up to six alphameric 

characters) of the DASD volume containing the minidisk that is 

the system residence volume of the system to be saved. 

¥SYSADR=cuu 

is the virtual address of the minidisk that is the system 
residence volume of the system to be saved. 

SYSVOL=cccccc 

is the volume serial number (up to six alphameric characters) 
of the DASD volume designated to receive the saved system. 
This must be a CP-owned volume. 

SYSCYL=nnn 

is the real starting cylinder of the minidisk (specified by 
VSYSRES and VSYSADR) that is the system residence volume of 
the system to be saved. 

SYSSTRT=(cc,p) 

designates the starting cylinder (cc) and page address (p) on 
SYSVOL at which this named system is to be saved. During the 
SAVESYS and IPL command processing, this is used to generate 
the "cylinder page and device" address for the DASD 
operations. These numbers are specified in decimal. 

I The number of pages written to this area is the total number 

I specified via the SYSPGNM operand, plus one information page. 
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SYSPGCT=pp 
I is the total number of pages (pp) you specify to be saved 

I (that is, the total number of pages you indicate via the 

I SYSPGNM operand) . This is a decimal number, up to two 

I digits. 

SYSPGNM= (nn,nn,nn-nn, . . .) 

are the numbers of the pages to be saved. Pages may be 
specified singly or in groups. For example: if pages 0, 4, and 
10 through 13 are to be saved, use the format: 
SYSPGNM= (0,U, 10-13). 

SYSHRSG=(s,s, ...) 

are the segment numbers designated as shared. The pages in 
these segments are set up at IPL time to be used by any user 
loading by this name. All segments to be shared must be 
reentrant. 

For example, a DHKSNT module to create a named CHS system could be 
coded as follows: 

DMKSNTBL CSECT 

FSTNAME NAMESYS SYSSIZE=320K, SYSNAME=CMS, VSYSRES=CPDSK1 , X 

VSYSADR=190,SYSCYL=100,SYSVOL=CPDSK2, X 

SYSSTRT=(400,1) ,SYSPGCT=33, X 

SYSPGNM= (0-32) ,SYSHRSG= (1) 
END 

Information on the following subjects is in the VM/370: System 
££231^316^1 s Guide. 

• Determining when to save a system. 

• Using the SAVESYS command. 

• Saving the CHS system. 

• Saved system restrictions for CMS. 

• Saving OS. 
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CODING THE NAMENCP MACRO 



You must create an entry in the system name table (DMKSNT) for each 

11 «% •: ^<« A nnnii /"inrtc ^_j... i -,_^ — j. i j. __— — j.~ -r^ ^— £ — 

uiij-^uc jiyj'^/jiyjj K^yj u \. i. Kj A. {Ji.uvjj.aui uuac juu yjvu.Kn.a. \.\s , xj. jruu (jaii x.vji.*£i>w 

generating several versions of the 3704/3705 control program, define 

extra entries in the system name table when you generate VM/370. In 

this way, you do not have to regenerate the VM/370 system just to update 
the system name table. 



Use the NAMENCP macro to define 3704/3705 program 
system name table. The format of the NAMENCP macro is: 



entries in the 



label i NAMENCP j CPSIZE=nnnK, 

CPNAME=ncpname, 
CPTYPE=(EP ) 
<NCP> 
(PEPJ, 
SYSPGCT=pp, 
SYSVOL=volser, 
SYSSTRT=(ccc,p) 



w h er e : 

label 

CPSIZE=nnnK 



is any desired user label. 

is the storage size of the 3704/3705 specified during the 
3704/3705 control program generation. 



CPNAME=ncpname is the name of the 3704/3705 control program image. This 
name is used in the SAVENCP and NETWORK LOAD commands. 
The name must be from one to eight alphameric 
characters. 



CPTYPE=f EP 
NCP 
PEP 

SYSPGCT=pp 



is the 3/04/3/05 control program type 



is the total number of pages (pp) to be saved. This 
value may be egual to the number of pages implied by the 
CPSIZE operand plus four pages, but it must not exceed 
that total. 



SYSVOL=volser is the volume serial number (volser) of the DASD volume 
designated to receive the control program image. That 
volume must be a CP-owned volume. 



SYSSTRT= (ccc,p) 



is the starting cylinder (ccc) and page address (p) on 
SYSVOL at which this image is to be saved. These numbers 
must be specified in decimal. 
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I Altering the Forms Control Buffer Load (DMKFCB) 



The DMKFCB module is supplied with the starter system. This module 
defines a 3211 forms control buffer image with 6 lines/inch, 66 
lines/page and the following channel skip specifications: 

Channel 

Line skip 
^6££§sented Specification 

1 1 

3 2 

5 3 

7 4 

9 5 

11 6 

13 7 

15 8 

19 10 

21 11 

23 12 

61 9 

If you wish to alter the supplied buffer load, see the VM/370: System 
Pgggiggggg-g JiiliJ® foJ^ directions. 
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Part 3: Generating VM/370 (CP. CMS. and RSCS) 



Part 3 describes the step-by-step generation procedures for CP, CMS, and 
RSCS and describes the Installation Verification Procedure (IVP) for CP 
and CMS. It contains the following sections: 

• Generating CP and CMS Using the 2314 Starter System 

• Generating CP and CMS Using the 3330 Starter System 

• Generating CP and CMS Using the 33U0 Starter System 

• Verifying CP and CMS Using the IVP 

• Generating and Installing RSCS 
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System Generation Procedures 



Before you start to install VM/370, be sure you have the following 
available: 

• Two real disk drives 

• At least one real tape drive (the system generation process is 
simpler if you use two tape drives) 

• Two scratch disks (one is used for the starter system and the other 
is used for the new system residence volume) 

• The starter system tape (s) 

• The PLC tape 

• At least one scratch tape 

The system generation procedures described in this manual refer to 
related publications. These publications are listed in the Preface. 

The following procedures for installing CP and CMS are described: 

• 2314 starter system 

• 3330 starter system 

• 3340 starter system 

Following the procedures for installing CP and CMS are the procedures 
for installing the optional RSCS (Remote Spooling Communications 
Subsystem) . 

In addition, the information you need to install the 3704/3705 
control program is found in "Part 4: Generating the 3704/3705 Control 
Program" and the information you need to install the standalone 2780 
Spool Remote Program is in "Part 5: The Standalone Spool Remote 
Program. " 
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GENESAL IMFORHATION 

CP and CMS have separate system residence disks which may be located on 
the same or different physical disks. The following procedure tells you 
how to generate the CP system residence disk or move the CMS system 
residence disk. Before you attempt to generate a VM/370 system, make 
sure that the real I/O configuration file (DMKRIO) , CP system control 
file (DMKSYS) , the VM/370 Directory file (DMKDIR) , and, optionally, the 
forms control buffer load (DMKFCB) and the system name table file 
(DMKSNT) are punched. Information about preparing these files is in 
"Part 2: Defining Your VM/370 System." If CMS is to be saved as a named 
system, be sure that the SAMESYS macro is coded correctly in the DMKSHT 
file. 

The VM/370 system is distributed on four 9-track tapes (1600 or 6250 

bpi) , or six 9-track tapes (800 bpi) that can be restored to direct 

I access volumes. You must specify the device type (2314/2319, 3330 or 

I 3340) when you order VM/370. You should also specify the tape density 

reguired (800, 1600, or 6250 bpi) . 

These basic tapes are as follows: 

• The VM/370 starter system (one or two tapes) contains the base level 
of both the CP and CMS systems, and the text decks with which to 
build these systems. 

• The CP2 tape contains all source files, text files, support 
procedures, macros, and the macro library of CP. 

• The CMS2 file (one or two tapes) contains all source files, text 
files, module files, support procedures, macros, and the macro 
library of CMS. 

• The PLC tape contains all source updates, text decks, modules, macros 
and macro libraries, and procedures reguired to build the latest 

I level of CP, CMS, and RSCS. 

I Three optional sets of tapes may also be ordered: 

• The Assembler tape containing source, macros, text, modules, and 
procedures for the Assembler. 

• CP assembly listings (three tapes) . 

• CMS assembly listings (two tapes) . 



160 VM/370: Planning 6 System Generation Guide 



2314 Starter System 
Generating CP and CMS Using the 2314 Starter System 



Except where otherwise noted, you can substitute other values in place 
of the device addresses, volume labels, and allocations shown. Note 
that if you use the sample DMKSNT and DMKSYS provided with the starter 
system, and use the sample allocations shown in Steps 2 and 3, you can 
save your CMS system at the end of the procedure. 

It is strongly recommended that you use the sample allocations given 
in Step 2 and the label VMREL2 for the new system residence volume, to 
ensure that you have sufficient TEMP space to complete the system 
generation* (The TEMP space provided on the starter system volume may 
not be sufficient for large systems.) 

I Note: The 2314 starter system cannot be generated on a real System/370 
I with a console address greater than 5FF hexadecimal. 

The examples of messages and responses assume that you are performing 
the system generation at a typewriter terminal, such as a 3210, 2741, or 
3767 (operating as a 2741) . If you are using a display device, such as 
the 3277, when you type the response to a prompting message, that 
response appears in the user input area. When you enter that response, 
it is redisplayed in the output area on the line below the prompting 
message. Also, if the standalone service programs (such as the DASD Dump 
Restore program or Format/Allocate program) send output to a terminal 
display screen, the output is wrapped around immediately, when the 
screen becomes full, to continue displaying. 

While you are generating the system, you may see some extraneous 
messages as the starter system is processing. These are not shown in 
the examples below. Only those messages that you should take note of or 
respond to are shown. 



STEP U LOAD THE FORMAT PROGRAM FROM THE STARTER SYSTEM TAPE 

Mount the CP starter system tape and IPL the tape. The CP 
Format/Allocate service program is the first file on the tape; it is now 
loaded. Do not rewind the tape because the next file is needed later in 
the system generation procedure (Step 4) . 



STEP 2. FORMAT, LABEL, AND iLI-OCATE THE SYSTEM RESIDENCE VOLOME 

I Ose the CP Format/Allocate program to format, label, and allocate space 
on the new system residence volume. First, identify the system console 
by pressing the Request key (or equivalent) ; if the console address is 
either 009 or OIF, you do not have to press the Request key. Then, to 

I execute the Format/Allocate service program, respond to the prompting 
messages. 

In the following example, the responses (format, 131, 2314, 000, 202, 
and vmrel2) format the 2314 disk at address 131 and label it VMREL2. 
Whatever label you specify must match what you specified on the SYSVOL 
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2314 Starter System 

operand of the SYSRES lacro when you defined the systea. In any case, 
do not use CPV2L0 because that is the label of the starter system disk. 
The console output is: 

VM/370 FORMAT/ALLOCATE PROGRAM VERSION 2.0 

ENTER FORMAT OR ALLOCATE: format 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 131 

ENTER DEVICE TYPE:231t| 

ENTER START CYLINDER (XXX) OR "LABEL'MOOO 

ENTER END CYLINDER (XXX):202 

ENTER DEVICE LABEL: vmrel2 

FORMAT STARTED 

FORMAT DONE 

000 PAGE RECORDS FLAGGED 

When the format operation completes, the prompting message 

ENTER FORMAT OR ALLOCATE: 

is displayed. Now that the system residence volume is formatted and 
labeled, you must allocate the disk space. Again, you must respond to 
the prompting messages. In the following example, the space on the 2314 
disk at address 131, with the label VMREL2, is allocated (9 cylinders of 
permanent space, 4 cylinders of directory, 177 cylinders of temporary 
space, and 13 cylinders of TDSK space.) You can use the formulas given 
in the "Creating Your VM/370 Directory" section of Part 2 to ensure that 
4 cylinders is enough space for your VM/370 directory. If you do not 
allocate your DASD space as shown in this example, you are responsible 
for ensuring that you have enough temporary space to perform the 
assemblies associated with VM/370 system generation. 

ENTER FORMAT OR ALLOCATE: allocate 

ALLOCATE FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 1 31 

ENTER DEVICE TYPE:2314 

ENTER DEVICE LABEL: vmrel2 

ENTER ALLOCATION DATA FOR VOLUME VMREL2 

TYPE CYL CYL 



perm 000 008 

drct 009 012 

temp 013 189 

tdsk 190 202 

end 

ALLOCATION RESULTS 

PERM 000 008 

DRCT 009 012 

TEMP 013 189 

TDSK 190 202 

DEVICE 131 VOLUME VMREL2 ALLOCATION ENDED 

ENTER FORMAT OR ALLOCATE: 



STEP 3. LABEL THE STARTER SYSTEM VOLUME 

Use the Format/Allocate program to label the scratch volume that is to 
contain the CP starter system. This label must be CPV2L0. You can 
format and label this volume, or just label it. Formatting is 
unnecessary because you are going to restore the starter system to this 
volume. In the following example, the responses (format, 130, 2314, 
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label, and cpv210) to the prompting messages put the label CPV2L0 on the 
2314 disk at address 130. 

ENTER FORMAT OR ALLOCATE: format 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 130 

ENTER DEVICE TYPE:2314 

ENTER START CYLINDER (XXX) OR "LABEL" : label 

ENTER DEVICE LABEL: cpv210 

LABEL IS NOW CPV2L0 

I When the Format/Allocate program is complete, it responds: 

ENTER FORMAT OR ALLOCATE: 

¥oa do not have to respond to this message. 

Now the volume is available and ready for the data that is to be 
placed on it by the DASD Dump Restore service program (module DHKDDR) . 
The DASD Dump Restore program is the second file on the starter system 
tape. 



STEP 4. LOAD THE DASD DDMP RESTORE PROGRAM FROM THE STARTER SYSTEM TAPE 

IPL the starter system tape a second time to load the DASD Dump Restore 
(DDR) program. It is the second file on the starter system tape. Do 
not rewind the tape, because the next file is needed in Step 5. 



STEP 5. RESTORE THE STARTER SYSTEM TO DISK 

Respond to the DDR prompting messages to restore the starter system. 

In the following example, the starter system is restored from the 
2400 series tape drive at address 280 to the 2314 disk at address 130 
(and with label CPV2L0,) The console output is: 

VM/370 DASD DOME/RESTORE PROGRAM VERSION 2.0 

ENTER CARD READER ADDRESS OR CONTROL STATEMENTS 

ENTER: sysprint cuu (cuu=real printer address) 

ENTER: input 280 2400 (See the "Special Considerations for 800 BPI Tapes" 

section, if you ordered your starter system on 800 bpi tape) 
ENTER: output 130 2314 cpv210 
ENTER: restore all 
RESTORING CPV2L0 
END OF RESTORE 

ENTER: (null line — END key on 3215 or Enter key on 3277) 
END OF JOB 

The DDR program restores the third file on the starter system tape to 
the disk labeled CPV2L0. The restored disk contains: 

• A VM/370 directory file (RELEASE2 DIRECT), as well as sample source 
for DMKSYS, DMKSNT, and DMKFCB 

• A VM/370 starter system nucleus 

• A CMS system residence volume 

• A CP system comprised of macro libraries and text files 
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When the disk is restored, continue with the system generation 
procedure. The format of the restored disk is shown in Figure 17. 



r ' ,., , . .,._ _.. - ,.,...,. ... 

1 Real 1 Number of | 

1 Cylinder | Cylinders | Contents 


1 1 1 1 VM/370 directory 


1 1 1 1 1 191 minidisk for the IVPMI user 


1 2 1 1 1 191 minidisk for the IVPM2 user 


1 3 1 1 1 191 minidisk for the BEM2780 user 


1 U-6 1 3 1 CP nucleus 


1 7 1 1 1 Warm start data 


1 8-9 1 2 1 I/O Error Recording area 


1 10-33 1 24 1 Spooling and paging space 


1 3U 1 1 1 191 minidisk for the CPGEN user 


1 35-144 1 110 1 190 minidisk (the CMS system disk) for the 
1 1 1 CMSSYS user 

1 1 1 Note: The last two cylinders of the 190 

i 1 1 minidisk (143-144) contain the CMS nucleus. 


1 154-202 1 58 1 194 minidisk of the CPGEN user - it contains 
1 1 1 the CP object modules (text decks) 



Figure 17. Format of a 2314 Restored Disk 



Figure 17 represents the allocation of areas on a 2314 starter system 
volume. 

CPGEN, CMSSYS, IVPMl, IVPM2, and REM2780 are user identifications 
that own certain minidisks on the starter system volume. 

CPGEN is the userid of the operator (that is, you use this userid to 
control the real system and to build a version of CP tailored to your 
installation. 

CMSSYS is a directory entry on the starter system volume that owns 
CMSSYS 190 (the CMS system disk). CPGEN has a read-only link to CMSSYS 
190 in order to use it to create the new system. Using this link, the 
CPGEN user can read from, but not write on, the 190 minidisk belonging 
to the CMSSYS user. 

IVPMI and IVPM2 are used with the Installation Verification Procedure 
to test the new system. 

REM2780 is used to test the 2780 as a remote entry station. 
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SPECIAL CONSIDERATIONS FOR 800 BPI TAPES 



If you ordered the starter system on 800 bpi tape, you have two tapes. 
If you have two tape drives available for the system generation 
procedure, use the following form of INPUT statement: 

input 280 2U00 281 

In this case, when DDR finishes reading the first tape volume, it issues 
the message: 

END OF VOLUME CYL XXX HD XX, MOUNT NEXT TAPE 

and continues by reading the tape mounted on the alternate tape drive 
(281). If you have only one tape drive available, you enter an INPUT 
statement in the form: 

input 280 2U00 

When the end-of-volume message appears, you must demount the first tape, 
mount the second tape on the same device and ready the device. Then, 
the DASD Dump Restore program continues by reading the second tape. 



STEP 6. IPL THE STARTER SYSTEM 

You now load (IPL) the starter system from the disk you restored it to. 
In our example, you press the Load pushbutton with the load unit address 
dials set to 130. At this point, only the device containing the system 
residence volume, 130, is known to the starter system. 



STEP 7. DEFINE THE DEVICES NEEDED TO DO THE SYSTEM GENERATION 

If your system console is at an address other than 009 or OIF, after you 
load the starter system you must press the Request key (or equivalent 
key) to enable the starter system to recognize the system console. If 
the console is not recognized, the VM/370 starter system enters a wait 
state. 

At this point both the system residence volume and system console are 
recognized by the starter system and you can define the other devices 
you need. The starter system supports up to 16 channels, 8 control 
units, and 16 devices. The real control blocks for these devices are not 
built in the standard manner; the starter system builds them 
dynamically. 

The starter system program (DMKSSP) then prompts you to answer the 
following questions until all the real control blocks necessary to 
operate a minimum machine configuration are created. The following 
example assumes: a 1i{03 printer at address OOE, a 2540 card reader/punch 
at addresses OOC (reader) and OOD (punch), tape drives at addresses 280 

I and 281, and a 231U DASD at address 131. You must respond to the 

I message 

I ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (CUU) : 

I with the same device address you specified on the SYSRES operand of the 
I SYSRES macro in your system control file (DMKSYS) . 
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If you are doing the system generation in a virtual machine, you must 
respond "no" to the message 

CHANGE TOD CLOCK (YES | HO): 

I You must also respond to messages to set the date and time. If you 
I are using a 3270 display device to generate VM/370 from the starter 
I system for the first time, the 3270 locks when you try to respond to the 
I message 

I SET DATE MM/DD/YY: 

I The System Available and Input Inhibited lights are on. You must press 
I the Reset key and move the cursor to the second position of the input 
I area before responding to the message. You follow this procedure only 
I the first time the system is defined. 

When asked what kind of start this is, you must respond "cold". The 
messages you receive at this time are: 

VM/370 STARTER SYSTEM VERSION 2.0 

ENTER PRINTER ADDRESS (CUU) : OOe 
ENTER DEVICE TYPE (1403, 1443, 321 1) : 1 403 
ENTER PUNCH ADDRESS (CDU) : OOd 
ENTER DEVICE TYPE (2540P, 3525) : 2540p 
ENTER READER ADDRESS (COU) : OOc 
ENTER DEVICE TYPE (250 1 ,2540R, 3505) : 2540r 
ENTER ADDRESS HHERE PID TAPE IS MOUNTED (CUU):280 
ENTER DEVICE TYPE (240 1 , 24 15, 2420, 3420) : 2401 
ENTER ADDRESS WHERE SCRATCH TAPE IS MOUNTED (CUU) :281 
ENTER DEVICE TYPE (240 1 , 24 15, 2420, 3420) : 240 1 

ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (CUU): 131 
I ENTER DEVICE TYPE (2319, 23 14, 3330, 2305) : 23 14 

♦♦♦SYSTEM DEFINITION COMPLETED^^^ 

OOE PRINTER 
OOD PUNCH 
OOC READER 

280 PID TAPE 

281 SCRATCH TAPE 

131 NEW SYSTEM RESIDENCE 

ARE THE ABOVE ENTRIES CORRECT (YES, NO) :yes 

VM/370 VERSION vv LEVEL PLC 0000; mm/dd/yy hh:mm:ss 

NOW 08:54:23 EDT FRIDAY mm/dd/yy 

CHANGE TOD CLOCK (YES | NO): yes 

SET DATE MM/DD/YY : mm/dd/yy 

SET TIME HH:MM:SS :09:04:36 

PRESS "TOD ENABLE SET" KEY AT DESIGNATED INSTANT 

NOW 09:04:36 EDT FRIDAY mm/dd/yy 

CHANGE TOD CLOCK (YES|NO):no 

09:04:38 START ((COLD|WARM) (DRAIN) ) | (SHUTDOWN) :cold 

09:04:40 

09:04:42 LOGON AT 09:04:37 EST FRIDAY mm/dd/yy 

LINE OIF LOGON AS CPGEN USERS= 001 

09:04:42 

DMKCPI952I nnnnK SYSTEM STORAGE 

If you have not defined your system residence volume with a label of 

I VMREL2, two messages are issued indicating that the volume labeled 

VMREL2 is not mounted. If you have labeled it as VMREL2, a message 
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indicating VMREL2 conflict is issued. You can ignore the following 
■essages. 

09:04:43 FILES: NO RDR, NO PRT, NO PON 
09:04:44 

DMKIOG556I FORMATTING I/O ERROR RECORDING MASK 

09:04:46 

DMKIOG557I FORMATTING MCH ERROR RECORDING AREA 

The TOD clock referred to is the System/370 Time of Day clock. Enter 
the actual date and time in response to the "SET DATE" and "SET TIME" 
messages, and press the "TOD ENABLE SET" switch on the system control 
panel when the exact time specified agrees with the installation wall 
clock. 

If, for some reason, you must reload the starter system, the 
following messages are displayed: 

VM/370 STARTER SYSTEM VERSION 2.0 

DO YOU WISH TO RE-DEFINE YOUR SYSTEM (YES|NO): 

Respond by entering "no", unless the failure was the result of 
incorrectly specifying the device addresses, or unless the tapes and/or 
disks have been moved. If you reply "yes", you repeat Step 7. 



STEP 8. SET THE TERMINAL MODE AND SPOOL THE CONSOLE 

If the system console you are using is a display device, you should at 
this point, spool your console output so that you have a record of what 
you do. To spool the console input and output, issue the command: 

spool console start 

to save a copy of the system feneration^ 

Because the default terminal environment for the primary system 
operator is CP, you should also issue the command: 

terminal mode vm 

The virtual machine terminal mode lets you remain in the CMS environment 
when you enter data on the display device. 



STEP 9. DEFINE OR ATTACH THJ SYSTEM RESIDENCE DEVICE 

The CPGEN virtual machine assumes that the system residence volume is 
labeled VMREL2 and is at virtual address 350 if the device type is 2314 
or at virtual address 351 if the device type is 3330. If you labeled 
your system residence volume VMREL2 in Step 2, your system residence 
device is already available; now you, as the operator of CPGEN, must 
define it. Use Procedure 1 to define your system residence device. 

If you did not label your system residence device VMREL2, you must 
attach it to your virtual machine, CPGEN, now. Use Procedure 2 to attach 
your system residence device. 
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For example, if you used the values shown in Step 7, you designated 

the 131 drive, labeled VMREL2, as your system residence drive for the 

generation procedure. Now you must define your virtual device 350 so 
that it corresponds to the real disk 131. 

Use one of the following procedures to define or attach your system 
residence volume: 

• Procedure 1 

If you labeled your system residence volume VMBEL2, but did not 
define its address as 350, you must do so now. Press the Request key 
and enter the command: 

define 350 as 131 

You, as the operator of the CPGEN virtual machine, gain ownership of 
that entire volume as virtual address 350. The CP DEFINE command 
maps this virtual address to the real address of your system 
residence volume as defined in your DHKSYS module. 

Remember that you restored your starter system tape to a 231U 
device. If you are now creating a 3330 system residence, with label 
VHREL2, issue the command: 

define 351 as 131 

You cannot create a 3340 system residence directly from a 2314 
starter system. However, a 3340 starter system is provided and a 
procedure for generating a 3340 system residence volume from a 
current 2314 or 3330 system residence volume and a PLC tape is 
described in Appendix H. VM/370 recommends that you use the 3340 
starter system. 

• Procedure 2 

If you did not label your system residence volume as VMREL2, you must 
attach your system residence volume to your virtual machine now. 
Press the Request key and enter the command: 

attach 131 to cpgen as 131 

Note: The first device address you specify is for the real device; 
the second device address is for the virtual device. The real 131 is 
the system residence volume you formatted in Step 2. The virtual 131 
is the system residence device defined in DMKSYS (with the SYSRES 
macro) and also entered in response to the message: 

ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (COU) : 



STEP JO. JAKE OTHER DEVICES AVAILABLE 

You must attach your tape drives and designate the printer to receive 
abnormal termination dumps if they occur. Press the Request key to 
enter each of the following commands: 

attach 280 to cpgen as 181 
attach 281 to cpgen as 182 
set dump OOe 
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In the first comiand. the real tape drive (280) attached nust be the 
saie real address you entered in Step 7 in response to the message: 

EHTEB ADDRESS WHERE PID TAPE IS MOUNTED (CUD) : 

This real device must be attached to CPGEN as 181, because the VMFBLD 
EXEC procedure (ffhich is used later) expects it to be 181. 

In the second command, the real tape drive (281) attached must be the 
same real address you entered in Step 7 in response to the message: 

ENTER ADDRESS WHERE SCRATCH TAPE IS MOUNTED (CUU) : 

This real device must be attached to CPGEN as 182, because the GENERATE 
EXEC procedure (which is used later) expects it to be 182. 

If only one tape drive is available, enter 

attach 280 to cpgen as 181 

You can define your virtual 181 as 182 later in the system generation 
procedure. 

The address of the real printer, defined in Step 7, is OOE. Any 
system dumps that occur are directed to that address. 

If you wish, you can issue the CP command: 

query virtual all 

before and after performing Step 10, to see how your virtual machine's 
configuration changes. 

STEP JJ. LOAD CMS 

Next, you must load CMS from virtual address 190 by issuing the CP 
command: 

ipl 190 

After CMS is loaded, a message is displayed on the system console 
indicating that CMS has successfully loaded: 

CMS VERSION 2.0 mm/dd/yy hh.mm 

Press the Return key and the CPGEN 191 minidisk is accessed as your 
A-disJc. 

STEP J2. LOAD THE PLC (PROGRAM LEVEL CHANGE) TAPE 

Demount the PID (Program Information Department) starter system tape, 
and mount and ready the PLC tape at 280. 

The PLC tape is prepared by the VM/370 Program Level Change (PLC) 
service. This is a system update service that can include new functions 
as well as cumulative system changes. The latest PLC tape contains all 
new updates, as well as all previous updates since the last VM/370 
release base. IBM Field Engineering is responsible for initially 
ordering the PLC service. Thereafter, PID automatically ships the PLC 
tapes to the FE location, and FE is responsible for applying the updates 
to VM/370 systems. 
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The PLC tape supplied with the starter system should be installed as 
part of the system generation procedure. Issue the CMS command: 

tape load 

The system issues the following messages: 

LOADING 

VMPBLD EIEC A1 

END-OF-FILE OR END-OF-TAPE 

R; 

The VMFBLD EXEC procedure is a service program that adds or replaces 
CP, CMS, or RSCS object modules. It loads the updates from the PLC tape 
for you. Issue the command: 

access 191 c 

because VMFBLD accesses other disks as its A-disk during processing. 
Next, issue the command: 

vmfbld cp 

to execute VMFBLD. 

The VMFBLD EXEC prompts you with the message: 

ENTER CP STAGING AREA DISK ADDRESS: 
194 

You respond with 194. The 194 minidisk belongs to the CPGEN virtual 
machine and is the area on the restored starter system volume that 
contains all the object modules necessary to generate a CP nucleus. The 
contents of the minidisk are updated with the latest versions of all 
object modules, as well as the latest version of the DMKMAC macro 
library. The following message is displayed: 

ARE YOU A NEW USER? — RESPOND (YES | NO) 

You must respond "yes" to this question. The following messages are 
then displayed: 

• 190" REPLACES "A (194) • 

190 ALSO = S-DISK 

hh:mm:ss REWIND COMPLETE 

CMS VERSION v.O - mm/dd/yy hh.mm 

The VMFBLD EXEC procedure links to the CMS system disk and accesses it 
as the A-disk. Next, VMFBLD reads the updated service programs from the 
PLC tape and writes them to the CMS S-disk. Then VMFBLD loads the new 
CMS system onto the system disk. 

After CMS is loaded, a message is displayed to indicate that the CMS 
system was successfully loaded: 

CMS VERSION v.O - mm/dd/yy hh.mm 

You must enter enter a null line to continue. 



STEP 13. PUNCH THE SERVICE PROGRAMS 

Use the GENERATE EXEC procedure to punch the service programs. Issue 
the command : 
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generate srvcpgm 



These service programs are needed for standalone use; you should 
externally identify the decks and keep them intact. 

The programs punched are: 

• DMKFMT (a three-card loader precedes the DMKFMT text deck) 

• DBKDIR (a three-card loader precedes the DMKDIR text deck) 

• DMKDDR (a three-card loader precedes the DBKDDR text deck) 

• IBCDASDI (the IBCDASDI text deck is loadable) 

The GENERATE EXEC issues the following message: 

THE FOLLOWING STANDALONE SERVICE PROGRAMS ARE BEING PUNCHED 
** FORHAT - DIRECT - DUMP/RESTORE - IBCDASDI ** 

PUNCHING • IPL FMT • ****** 

PUNCHING • IPL DIR ' ****** 

PUNCHING • IPL DDR • ****** 

PUNCHING • IPL IBCDASDI • ****** 

Each program deck is preceded by a CP userid card and several 
separator cards, all of which may be discarded. The format of these 
cards is described in the VM^370: Opera tor j_s Guide. 

For more information about the GENERATE EXEC procedure, see "Part 6: 
Updating VM/370." 



STEP J 4. PRINT AND PUNCH THE STARTER SYSTEM SUPPLIED DIRECTORY, DMKSNT, 
DMKSYS, AND DMRfCB 

After the service programs are punched, the GENERATE EXEC asks you 
whether you want a copy of the Release 2 directory printed. You should 
respond "yes." 

PRINT COPY OF RELEASE2 DIRECT? — RESPOND (YES|NO) : yes 

This prints a copy of the Release 2 directory, as well as copies of the 
DMKSYS ASSEMBLE (the CP system control file) , DMKFCB ASSEMBLE (the forms 
control buffer file) , and DMKSNT ASSEMBLE (the system name table) 
provided with the starter system. 

The GENERATE EXEC procedure issues the following message: 

A SAMPLE DIRECTORY IS BEING PRINTED TO AID YOU. 
IT SHOWS WHERE THE VIRTUAL DISKS ARE LOCATED ON •CPV2L0' 
YOU MAY USE THESE MINIDISKS FOR OTHER VIRTUAL MACHINES, 
IN PARTICULAR THE CMS SYSTEM DISK ( MAINT 190 ) AND 
THE CP STAGING AREA DISK ( MAINT 194 ) 
INCLUDED IN THIS DIRECTORY IS THE USERID: MAINT 
WHICH WILL BE USED FOR FUTURE SUPPORT OF THE SYSTEM. 
THIS USERID SHOULD BE INCLUDED IN THE DIRECTORY 
YOU BUILD FOR YOUR FLOOR USE. 

** CAUTION ** IF YOU DESTROY USER MAINT'S AREAS, IT WILL BE 
NECESSARY TO RE-BUILD THE ENTIRE SYSTEM. 
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A SAMPLE OF DMKSYS, DMKFCB, AND DMKSNT ASSEMBLE ARE ALSO BEING 

PRINTED TO AID YOU. THIS SAMPLE DMKSNT IS BASED ON THE 

INFORMATION INCLUDED IN THE SAMPLE DMKSYS AS WELL AS THE 

EXAMPLE ALLOCATIONS FOR VMREL2 PROVIDED IN THE SYSGEN GUIDE. 

A COPY OF THIS DMKSNT MODULE HAS BEEN INCLUDED IN THE CP NUCLEUS, 

SUCH THAT IF ONE USES THE INCLUDED DMKSYS AND THE 

SAMPLE ALLOCATION PROVIDED IN THE SYSTEM GENERATION GUIDE, 

HE WILL BE ABLE TO SAVE HIS CMS SYSTEM UPON COMPLETION 

OF THE SYSTEM GENERATION PROCEDURE. A COPY OF DMKFCB HAS BEEN 

INCLUDED IN THE NUCLEUS AND NEED NOT BE RE-ASSEMBLED FOR 

SYSTEM GENERATION. IT HAS BEEN INCLUDED FOR THE USER WHO WOULD LIKE 

TO MODIFY OR ADD TO THE EXISTING BUFFER LOAD. 

NOTE: IF THE USER WISHES TO MODIFY THE SAMPLE DMKSNT AND/OR DMKFCB 
HE MAY INCLUDE THE UPDATED SOURCE WITH THE SOURCE INCLUDED UNDER 
THE OPTION 'GENERATE VM370', OF THE SYSTEM GENERATION PROCEDURE. 
IF PRESENT, IT WILL AUTOMATICALLY BE ASSEMBLED AND INCLUDED IN THE 
NEW CP NUCLEUS. 

Again, the GENERATE EXEC procedure prompts you: 

DO YOU WISH TO HAVE A COPY OF DMKSNT, DMKSYS, DMKFCB, AND 
RELEASE2 DIRECT PUNCHED TO CARDS? — RESPOND (YES|NO): 

I You should enter "yes" to have these decks punched. "Part 2: Defining 

I Your VM/370 System" contains a listing of the Release 2 directory and 

I the DMKSNT, DMKSYS, and DMKFCB modules supplied with the starter 

I system. The following messages are issued to indicate the files that 
are being punched: 

PUNCHING • DMKSNT ASSEMBLE ' ****** 

PUNCHING • DMKSYS ASSEMBLE • ****** 

PUNCHING • DMKFCB ASSEMBLE ' ****** 

PUNCHING • RELEASE2 DIRECT ' ****** 

R; 



STEP 15. BUILD THE VM/370 DIRECTORY AND ASSEMBLE THE FILES DEFINING THE 
Mhk IIQ. kl^U SYSTEM DEVICES 

Next, you should place tt\e files describing your installation's version 
of the VM/370 directory, real I/O configuration, and system devices in 
the reader and invoke the GENERATE EXEC procedure to build the directory 
and assemble the files describing the configuration. Place the 
following cards in the card reader, in the seguence shown: 

ID CPGEH 

:READ filename DIRECT 

(Directory program control statements) 

:READ DHKRIO ASSEMBLE 

(Real I/O configuration macros) 

:READ DMKSYS ASSEMBLE 

(CP system control file macros) 

The Directory program control statements, real I/O configuration macros, 
and CP system control file macros are those you created according to the 
instructions in "Part 2: Defining Your VM/370 System." You can code 
your own system control macros or add to the file supplied with the 
starter system. 
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Also, if you want, you can change the printer buffer load (DMKFCB) or 
the named system (DMKSHT) modules to conform to local requirements. If 
you want to change the printer buffer load or the system name table, you 
should add your changes to the files already punched (in Step 1U) and 



file macros: 






,-,^4.^,-, ■ 



:READ DMKFCB ASSEMBLE 
(forms control macros) 
:READ DMKSNT ASSEMBLE 
(system name table macros) 

Instructions for creating new forms control macros are in the yM/370: 
System Programmer's Guide. The system name table macros are described 
in "Part 2: Defining Your VM/370 System" of this manual. 



FORMAT OF THE READ COSTROL STATEMENT 



The READ 
format: 



control statements must be punched according to the following 





Number 


of 


1 








Column 


Characters 


[Contents 


Meaning 






1 


1 




1 colon' : ' 
1 


Identifies card 


as a 


control card 


2-5 


4 




1 

IREAD 


Identifies card 


as a 


READ control card 


6-7 


2 




1 
{blank 








8-15 


8 




1 

1 f name 


Filename of the 


file 


punched 


16 


1 




1 
{blank 








17-24 


8 




1 

If type 

1 


Filetype of the 


file 


punched 


25-80 


56 




1 
{blank 









SPECIAL PROCEDURE IF YOU ARE USING ONLY ONE TAPE DRIVE 



If you are using only one tape drive, at this time you must issue the 
command: 

define 181 as 182 

How mount the scratch tape in place of the PLC tape and ready the 
device. 



INVOKE THE GENERATE EXEC PROCEDURE 



When all the files are placed in the reader, invoke the GENERATE EXEC 
procedure by issuing the following command: 

generate vm370 
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This procedure invokes the Directory service prograi to build the 
disk-resident VB/370 directory, then assembles the DMKRIO and DMKSYS 
files that you placed in the real card reader. After the Directory 
service program execution completes, the DMKRIO and DMKSYS files are 
assembled in preparation for building the new CP system nucleus. 
GENERATE then checks for DMKFCB and DMKSNT source files. When new 
versions of the DMKFCB and DMKSNT modules are provided, GENERATE 
assembles the new modules and replaces the corresponding modules 
supplied with the starter system with the new modules. If any errors 
occur while the VM/370 directory is being built, the Directory program 
issues error messages and the GENERATE EXEC procedure issues the 
following message: 

CORRECT THE DIRECTORY CARDS AND RELOAD THE CARD READER 
RESPOND WITH: GENERATE DIRECT 

Correct the errors in the Directory program control statements, and 
reload the card reader with only the ID card, the :READ statement, and 
the Directory program control statements. Then respond with: 

generate direct 

If errors are detected while the DMKRIO, DMKSYS, DMKFCB, or DMKSNT 
files are assembling, GENERATE issues a similar message: 

CORRECT THE filename ASSEMBLE FILE AND RELOAD THE CARD READER 
RESPOND WITH: GENERATE filename 

You must correct the errors in the indicated file, and reload the card 
reader with only the ID card, the :READ statement, and the appropriate 
file. Then, issue the GENERATE command with the appropriate option. 
For example: 

generate dmksys 



STEP J6. SPECIAL CONSIDERATIONS FOR VIRIDAL=REAL MACHINES 

Once the directory is built and the files are assembled, the GENERATE 
EXEC procedure asks if you want the virtual=real option included in your 
CP nucleus: 

VIRTUAI=REAL OPTION REQUIRED (YES, NO) : 

If you respond "yes" to this guestion, you are prompted to enter the 
amount of storage you wish to reserve in the CP nucleus for a 
virtual=real machine. ("Part 1. Planning for System Generation" 
contains formulas to help you determine how much storage you need to 
reserve.) This size must be a multiple of UK and must be entered in the 
format nnnnK. The minimum size you can specify is 32K and the maximum 
is 4M. For example: 

STORAGE SIZE OF VIRT=REAL (MINIMUM IS 32K) : 

100k 

0100K STORAGE SIZE FOR VIRTUAL=REAL 

IS THE ABOVE ENTRY CORRECT (YES, NO): 

yes 
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STEP 12* iQAD ISl CP NUCLEUS 

Once you respond to the virtual=real generation questions, the GENERATE 
EXEC procedure writes the CP nucleus on tape. To do this, GENERATE 
first issues the the VMFLOAD command to punch the loader and CP object 
modules to a virtual punch spool file. Then it transfers this file to 
the virtual card reader file and writes the file on tape. GENERATE 
issues the following messages during the processing: 

hh:mm:ss NO FILES PURGED 
SYSTBM LOAD DECK COMPLETE 

hhzmmrss PUN FILE nnnn TO CPGEN COPY 01 NOHOLD 
IPLABLE NUCLEUS NOW ON TAPE *♦♦* 

hh:mm:ss PRT cuu OUTPUT OF CPGEN FILE-nnnn RECDS^nnnnnn 
COPY = 01 A PRT 

Note: If any errors are detected while the tape is being written, you 
must recreate the CP nucleus. To do this, issue the command: 

generate cp nucleus 

The procedure restarts at Step 16 where you are asked if you want the 
virtual=real option. 



LOADING A CP NUCLEUS WITHOUT A VIRTUAL=REAL AREA 

If you responded "no" when asked if you wanted the virtual=real area, 
the GENERATE EXEC procedure loads the nucleus for you. You receive the 
following message: 

WHEN 'NUCLEUS LOADED OH XXXXXX' IS TYPED, ISSUE 'CLOSE PRT', 
TO GET THE CPLOAD MAP. WHEN PRINTING IS COMPLETE, 
SHUTDOWN THE SYSTEM AND IPL THE NEW SYSRES VOLUME. 

When the nucleus is written on the system residence volume, the message 

NUCLEUS LOADED ON volid 

is issued, where volid is the volume serial number of your system 
residence volume. The volid is the serial number you specified on the 
SYSRES macro when you prepared the CP system control file (DMKSYS) . If 
you followed the example in this manual, the serial number of your 
system residence volume is VHREL2. 

To print the load map you must close the printer; issue the command: 

close prt 

When printing is complete, shutdown the system in preparation for 
loading your newly generated CP nucleus: 

shutdown 



LOADING A CP NUCLEUS THAT HAS A VIRTUAL=REAL AREA 

If you responded "yes" when asked if you wanted the virtual=real area, 
the GENERATE EXEC procedure issues the following message: 
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TO LOAD THE CP NUCLEUS JUST CREATED, SHUTDOWN THE SYSTEM AND 
THEN IPL THE TAPE. THE CPLOAD MAP HILL AUTOMATICALLY BE PRINTED AT THE 
PRINTER HHOSE ADDRESS IS 'OOE*. IF THERE IS NO PRINTER AT THIS ADDRESS 
THE LOAD MAP HILL BE PRINTED AT THE FIRST PRINTER CAUSING AN INTERRUPT, 
(IE. NOT-READY TO READY SEQUENCE). ONCE THE NUCLEUS HAS BEEN LOADED, 
YOU MAY IPL YOU NEH CP SYSTEM RESIDENCE VOLUME. 

NOTE: THERE MUST BE ENOUGH STORAGE ON THE SYSTEM (VIRTUAL OR REAL), TO 
CONTAIN THE VIRT=REAL AREA AND THE CP NUCLEUS. 

You must be sure that there is enough storage to load the CP nucleus 
with a virtual=real area before you load it. The "Specifying a 
Virtual=Real Machine" section of Part 1 tells you how to determine the 
amount of real or virtual storage you need. You can load a CP nucleus 
that has a virtual=real area in either a real or virtual machine. 

You IPL the tape containing the CP nucleus next. The CP nucleus is 
on the tape at virtual address 182 for the CPGEN virtual machine. 



STEP 18. IPL THE NEHLY GENERATED VM^370 

IPL the newly created system residence volume by setting the load unit 
address dials to the address of the system residence volume and pressing 
the Load pushbutton. The userid OPERATOR (or whatever userid you 
specified as the system operator on the SYSOPER macro) is logged on when 
you IPL. The following messages are issued. Respond as shown. 

VM/370 VERSION vv LEVEL 00 PLC nnnn; mm/dd/yy hh:mm:ss 

NOH hh:mm:ss EDT day mm/dd/yy 

CHANGE TOD CLOCK (YES | NO): no 

hh:mm:ss START ((COLDjHARM) (DRAIN) ) | (SHUTDOHN) : cold 

hh:mm:ss LOGON AT hh:mm:ss EDT day mm/dd/yy 

hh:mm:ss LINE OIF LOGON AS OPERATOR USERS = 001 

hh: mm: ss 

DMKCPI952I nnnnK SYSTEM STORAGE 

hh:mm:ss FILES: NO RDR, NO PRT, NO PUN 
hh:mm:ss 

DMKI0G556I FORMATTING I/O ERROR RECORDING AREA 

hh:mm:ss 

DMKIOG557I FORMATTING MCH ERROR RECORDING AREA 

At the time you IPL your newly generated VM/370, your system 
residence volume is formatted according to your specification on the 
SYSRES macro. Also, if you used the VM/370 directory supplied with the 
231U starter system, your starter system volume (CPV2L0) is set up as 
shown in Figure 18. Be careful not to modify the 190 and 19U minidisks 
for the MAINT user. These minidisks and the information they contain 
are reguired for applying PLC (Program Level Change) updates to VM/370. 
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Beal i Number of | 
Cylinder | Cylinders | Contents 



! nnnoc'l 



I 191 minidisk for the IVPM1 user 



I 191 minidisk for the IVPM2 user 



I 191 minidisk for the REM2780 user 



4-13 1 


10 


1 191 


minidisk 


for 


the OPERATOR user 


14-18 1 


5 


1 191 


minidisk 


for 


the CE user 


19-28 1 


10 


1 191 


minidisk 


for 


the MAIKT user 


29-33 1 


5 


1 191 


minidisk 


for 


the ECMODE user 


34 1 


1 


1 199 


minidisk 


for 


the MAINT user 



35-144 I 110 I 190 minidisk for the MAINT user 

I I 

I • I Note that the last two cylinders of this 

I I minidisk contain the CMS nucleus. 



145-202 I 58 I 194 minidisk for the MAINT user - it contains 
I I the CP object modules (text decks) 

I I 

Figure 18. Allocation of the VM/370 Starter System Volume (CPV2L0) when 
the 2314 Starter System Directory Is Used 



STEP 19. BACK UP THE Mlhl GENERATED VM/370 

At this time, you should be sure to back up your new system residence 
volume. If your real machine has at least 448K bytes of real storage, 
the tape created in Step 17 is sufficient backup. However, that tape is 
not sufficent backup for real systems with less than 448K of real 
storage because that tape cannot be loaded on such systems. 



VM/370 systems that run on a real machine with less than 448K bytes 
of real storage should use the DASD Dump Restore (DDR) service program 
to create a backup tape similar to the one created in Step 17. The DASD 
Dump Restore program is described in Appendix F. If your system 
residence volume is at address 131 and you labeled it VMREL2, you could 
use the following DDR control statements to tack it up: 

input 131 2314 vmrel2 
output 180 3420 
dump cpvol 

The tape produced contains the CP nucleus; it does not contain the 
VM/370 directory. However, you already created a standalone version of 
the Directory program in Step 13 and have the Directory program control 
statements, which you used in Step 15 to recreate the VM/370 directory. 

If you do not wish to use the DDR program to backup your system, you 
can load the tape produced in Step 17 in a virtual machine. If you load 
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I the tape in a virtual machine that virtual machine must have (1) 512K of 
I storage and (2) write-access to the system residence volume, at the 
I address defined for system residence in the SYSRES macro of the CP 
I system control (DMKSYS) file. 

I When you use the DDR program to backup your system, you do not get a 
I load map when you restore the tape. You do get a load map if you load 
I the tape produced in Step 17. 



STEP 20. MOVE THE CMS SYSTEM DISK, IP YOD WISH 

The CP nucleus just created is tailored to your installation's exact I/O 
configuration with all the appropriate options selected. The CMS nucleus 
requires no special tailoring for installation. The CMS system 
residence disk was created when the VM/370 starter system was loaded; it 
contains a copy of the CMS nucleus and disk-resident command modules. At 
this point, the CMS system resides on the virtual 190 disk for the user, 
MAINT. The operator's VM/370 directory has an entry that links to 
MAINT's 190 disk, therefore you can invoke CMS by issuing the command: 

ipl 190 

I and thus have access to most of the CMS functions. Although most of the 
I CMS functions are available, CMS has not yet been updated with the 
I latest PLC changes. The assembler that is available now is the one 
I supplied with the starter system. 

If you wish, you can move the CMS system disk to a disk other than 
the one designated by the starter system. To move the CMS system disk 
to another minidisk, use the COPY function of the DDR service program. 
The new minidisk should be the same size as the CMS system disk, but it 
does not need to be formatted. Also, if you move the CMS system, you 
must make the appropriate changes to the userid MAINT in your VM/370 
directory (that is, change the volume label on the MDISK entry for 
190) . 

If you add IBM Program Products or your own disk-resident modules to 
the CMS system disk, you may have to create a new system disk to contain 
the additional modules. The "Creating a CMS System Disk" section of 
"Part 6. Updating VM/370" tells you how to do this. 



STEP 21. FORMAT THE OPEHATORJ.S VIRTUAL J9J DISK 

Before any new minidisk area can be used for CMS files, it must be 
initialized with the CMS FORMAT command, which formats the area into 
800-byte blocks. Take care not to format areas which contain data 
restored from the starter system (such as the 190 and 194 minidisks 
belonging to the user MAINT.) The CMS FORMAT command is described in 
the VM/370 : Command L an^uage G uide for General Users . 

Note: After you complete this step, a portion of the starter system is 
overlaid by the operator's 191 minidisk. If for any reason you wish to 
IPL the starter system again, you must restart at step 1. 

At this time you are logged on as the operator. Use the following 
procedure to format your virtual disk 191. First, load CMS (IPL 190). 
CMS responds with: 

CMS VERSION 2.0 - mm/dd/yy hh:mm 
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Next, enter the following command: 

access (nodisk 

The nCDXSK optxou prevents CHS frois autouiaticaj.j.y accessxuCj jour vxrtuax 
disk 191. (Accessing 191 at this time would causes an error message to 
be issued because 191 is not yet initialized, and therefore cannot be 
used.) After the Ready message is displayed, issue the command: 

format 191 a 

The CMS FORMAT command prompts you with the following message: 

FORMAT HILL ERASE ALL FILES ON DISK 'A (191) •. DO YOD WISH TO 
COHTIMUE? (YES I MO): 

If you respond "yes", CMS prompts you with: 

ENTER DISK LABEL: 
opr191 

Enter the one- to six-character alphameric label of the virtual disk. 
You can use whatever label you wish for this virtual disk. In this 
example, the label is 0PR191. CMS then issues: 

FORMATTING DISK 'A» . 

•10» CYLINDERS FORMATTED ON •A(191)'. 

and a Ready message. 



STEP 22. FORMAT THE MAINT USERJ.S VIRTUAL 19J DISK 

Next, you should initialize the 191 disk belonging to MAINT, in the same 
way you initialized the operator's virtual 191. Log yourself off the 
system and log on again as userid MAINT, using the password CFCMS. Now 
IPL 190. When the CMS Ready message is displayed, issue 

access (nodisk 

and continue to format MAINT's 191, using the same procedure you used to 
format 0PR191. 



STEP 23. UPDATE CMS 

Now that the MAINT 191 minidisk is formatted, you (as the MAINT user) 
can update CMS with the changes supplied on the PLC tape. Mount the PLC 
tape, if it is not already mounted. You must attach the real tape drive 
to your CMS virtual machine (MAINT) ; for example: 

attach 280 to maint as 181 

and, with the 191 minidisk that belongs to MAINT accessed as your 
A-disk, rewind and load the tape: 

tape rew 
tape load 
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CMS responds with the following Message 

LOADING 

VMFBLD EXEC A 
END-OF-FILE OB END-OF-TAPE 



BUILDING A NEW CMS 

How execute the VMFBLD EXEC procedure by issuing the coimands: 

access 191 c 
vmfbld cms 

The VMFBLD EXEC procedure prompts you with: 

ENTER CMS SYSTEM DISK ADDRESS: 
You respond with "190". Next, VMFBLD issues the message: 

190 ALSO = S-DISK. 

You are asked if you want the service programs punched: 

PUNCH STANDALONE SERVICE PROGRAMS— RESPOND (YES|NO): 

The following messages are displayed; respond as shown: 

hh:mm:ss NO FILES PURGED 

hh:mm:ss NO FILES PURGED 

SYSTEM LOAD DECK COMPLETE 

hh:mm:ss PUN FILE nnnn TO CPGEN COPY 01 NOHOLD 

hh:mm:ss REWIND COMPLETE 

WHEN THE NEW CMS SYSTEM IS BUILT ISSUE THE FOLLOWING 

COMMAND 

CLOSE PRT . . . (PRINTS THE LOAD MAP) 

DMSINI605R SYSTEM DISK ADDRESS = 190 

DMSINI615R Y-DISK ADDRESS = 19e 

DMSINI607R REWRITE THE NUCLEUS ? yes 

DMSINI608R IPL DEVICE ADDRESS = 190 

DMSINI609R NUCLEUS CYL ADDRESS = 108 

DMSINI610R ALSO IPL CYLINDER ? yes 

DMSINI611R VERSION IDENTIFICATION = 

DMSINI612R INSTALLATION HEADING = 
CMS VERSION 2.0 -mm/dd/yy hh:mm 

In the example, the 190 you entered is the 190 minidisk that belongs 
to the user MAINT; it is equivalent to the 190 minidisk that belongs to 
CPGEN on the starter system. If you used the VM/370 directory supplied 
with the starter system, you allocated 110 cylinders (virtual cylinders 
0-109) to the 190 minidisk belonging to the user MAINT. The last two 
cylinders of this minidisk contain the CMS nucleus, therefore you 
specify cylinder 108 as the nucleus cylinder address when responding to 
message DHSINI609R. 

When the VMFBLD EXEC procedure completes its execution, the CMS 
system residence volume is updated with the most current object modules 
(text decks) and load modules, and the new CMS nucleus is written on the 
CMS system residence volume. 
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I Also, if there are any updates for the EBEP program or System 
I Assembler on the PLC tape, the VMFBLD EXEC procedure updates those 
I programs and creates the corresponding new auxiliary directory. 



STEP 24. SAVE CMS 

If you used the sample DMKSNT and DMKSYS supplied with the starter 
system, and used the sample allocations shown in Step 2, you can now 
save your CMS system. 

To save the CMS system, you must load it and then save it as soon 
after loading as possible. Issue the command: 

ipl 190 

When the terminal unlocks, do not press carriage return, but immediately 
issue the command: 

savesys cms 

Then press carriage return. If CMS is successfully saved, the message 

hh:mm:ss SYSTEM SAVED 

CMS VERSION 2.0 - mm/dd/yy hh:mm 

is displayed. Your CMS system is now saved; you can issue IPL CMS 
instead of IPL 190, when you wish to run CMS. 

If you named your CMS system something other than CMS, such as CMS1, 

the entry you made in the system name table would be for CMS1, you would 

I have to save CMS1 (SAVESYS CMS1) and then you could IPL CMS1. For more 

I information about how to save CMS, see the VM^370: System Programmer ^s 

I Guide or the "Saved Systems" section of this manual. 

At this point, use the Installation Verification Procedure (IVP) to 
test the new system. Log off as the userid MAINT and log on again as 
the userid OPERATOB, using the password OPERATOR. The IVP is described 
later in Part 3. 



Part 3: Generating VM/370 (CP, CMS, and RSCS) 181 



3330 Starter System 

Generating CP and CMS Using the 3330 Starter System 



Except where otherwise noted, you can, if you wish, substitute other 
values in place of the device addresses, volume labels, and allocations 
shown. Note that if you use the sample DMKSNT and DMKSYS provided with 
the starter system, and use the sample allocations shown in Steps 2 and 
3, you can save your CMS system at the end of the procedure. 

It is strongly recommended that you use the sample allocations given 
in Step 2 and the label VMREL2 for the new system residence volume, to 
ensure that you have sufficient TEMP space to complete the system 
generation. (The TEMP space provided on the starter system volume may 
not be sufficient for large systems.) 

I 52t§« The 3330 starter system cannot be generated on a real System/370 
I with a console address greater than 5FF hexadecimal. 

The examples of messages and responses assume that you are performing 
the system generation at a typewriter terminal, such as a 3210, 2741, or 
3767 (operating as a 2741). If you are using a display device, such as 
the 3277, when you type the response to a prompting message, the 
response appears in the user input area. When you enter that response, 
it is redisplayed in the output area on the line below the prompting 
message. Also, if the standalone service programs (such as the DASD Dump 
Restore program or Format/Allocate program) send output to a terminal 
display screen, the output is wrapped around immediately, when the 
screen becomes full, to continue displaying. 

While you are generating the system, you may see some extraneous 
messages as the starter system is processing. These are not shown in 
the examples below. Only those messages that you should take note of or 
respond to are shown. 



STEP J. LOAD THE FORMAT PROGRAM FROM THE STARTER SYSTEM TAPE 

Mount the CP starter system tape and IPL the tape. The CP 
Format/Allocate service program is the first file on the tape; it is now 
loaded. Do not rewind the tape because the next file is needed later in 
the system generation procedure (Step 4) . 



STEP 2. FORMAT, LABEL, AND ALLOCATE THE SYSTEM RESIDENCE VOLUME 

Use the CP Format/Allocate program to format, label, and allocate space 
on the new system residence volume. First, identify the system console 
by pressing the Reguest key (or eguivalent) ; if the console address is 
either 009 or OIF, you do not have to press the Request key. Then, to 
execute the Format/Allocate service program, respond to the prompting 
messages. 

In the following example, the responses (format, 350, 3330, 000, 403, 
and vmrel2) format the 3330 disk at address 350 and label it VMREL2. 
Whatever label you specify must match what you specified on the SYSVOL 
operand of the SYSRES macro when you defined the system. In any case, 
do not use CPV2L0 because that is the label of the starter system disk. 
The console output displays: 

182 VM/370: Planning & System Generation Guide 



3330 Starter System 

VM/370 FORMAT/ALLOCATE PROGRAM VERSION 2.0 

ENTER FORMAT OR ALLOCATE:f ormat 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU):350 

ENTER DEVICE TYPE: 3330 

ENTER START CYLINDER (XXX) OR "LABEL" :000 

ENTER END CYLINDER (XXX): 403 

ENTER DEVICE LABEL:vmrel2 

FORMAT STARTED 

FORMAT DONE 

000 PAGE RECORDS FLAGGED 

I When the format operation completes, the prompting message 

I ENTER FORMAT OR ALLOCATE: 

I is displayed. Now that the system residence volume is formatted and 

labeled, you must allocate the disk space. Again, you must respond to 

the prompting messages. In the following example, the space on the 3330 

disk at address 350, with the label VMREL2 , is allocated (7 cylinders of 

permanent space, 4 cylinders of directory, 379 cylinders of temporary 

I space, and 11 cylinders of TDSK space) . You can use the formulas given 

I in the "Creating Your VM/370 Directory" section of Part 2 to ensure that 

I four cylinders give enough space for your VM/370 directory. If you do 

I not allocate your DASD space as shown in this example, you are 

I responsible for ensuring that you have enough temporary space to perform 

I the assemblies associated with VM/370 system generation. 

ENTER FORMAT OR ALLOCATE : allocate 

ALLOCATE FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 350 

ENTER DEVICE TYPE: 3330 

ENTER DEVICE LABEL:vmrel2 

ENTER ALLOCATION DATA FOR VOLUME VMREL2 

TYPE CYL CYL 



perm 000 006 
drct 007 010 
temp 011 389 
tdsk 390 403 



end 

ALLOCATION RESULTS 

PERM 000 006 

DRCT 007 010 

TEMP 011 389 

TDSK 390 403 

DEVICE 350 VOLUME VMREL2 ALLOCATION ENDED 

ENTER FORMAT OR ALLOCATE: 



STEP 3. LABEL THE STARTER SYSTEM VOLUME 



Use the Format/Allocate program to label the scratch volume that is to 
contain the CP starter system. This label must be CPV2L0. You can 
format and label this volume, or just label it. Formatting is 
unnecessary because you are going to restore the starter system to this 
volume. In the following example, the responses (format, 351, 3330, 
label, and cpv210) to the prompting messages put the label CPV2L0 on the 
3330 disk at address 351. 
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ENTER FORMAT OR ALLOCATE: format 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 351 

ENTER DEVICE TYPE:3330 

ENTER START CYLINDER (XXX) OR "LABEL" :label 

ENTER DEVICE LABEL: cpv210 

LABEL IS NOW CPV2L0 

When the Format/Allocate program is complete, it responds: 

ENTER FORMAT OR ALLOCATE: 

You do not have to respond to this message. 

Now the volume is available and ready for the data that is to be 
placed on it by the DASD Dump Restore service program (module DMKDDR) . 
The DASD Dump Restore program is the second file on the starter system 
tape. 



STEP U. LOAD THE DASD DUMP RESTORE PROGRAM FROM THE STARTER SYSTEM TAPE 

IPL the starter system tape a second time to load the DASD Dump Restore 
(DDR) program. It is the second file on the starter system tape. 
Again, do not rewind the tape because the next file is needed in Step 
5. 

STEP 5. RESTORE THE STARTER SYSTEM TO DISK 

Respond to the DDR prompting messages to restore the starter system. 

In the following example, the starter system is restored from the 
2400 series tape drive at address 280 to the 3330 disk at address 351 
(and with label CPV2L0) . The console output is: 

VM/370 DASD DUMP/RESTORE PROGRAM VERSION 2.0 

ENTER CARD READER ADDRESS OR CONTROL STATEMENTS 

ENTER: sysprint cuu (cuu=real printer address) 

ENTER: input 280 2U00 (See the "Special Considerations for 800 BPI Tapes" 

section, if you ordered your starter system on 800 bpi tape) 
ENTER: output 351 3330 cpv210 
ENTER: restore all 
RESTORING CPV2L0 
END OF RESTORE 

ENTER: (null line — END key on 3215 or Enter key on 3277) 
END OF JOB 

The DDR program restores the third file on the starter system tape to 
the disk labeled CPV2L0. The restored disk contains: 

• A VM/370 directory (RELEASE2 DIRECT) , as well as sample source for 
DMKSYS, DMKSNT, and DMKFCB 

• A VM/370 starter system nucleus 

• A complete CMS system residence volume 

• A complete CP system comprised of macro libraries and text files 

Hhen the disk is restored, continue with the system generation 
procedure. The format of the restored disk is shown in Figure 19. 
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Real I Number of | 
Cylinder | Cylinders | Contents 



! 1 ! VM/370 riirat-^nrv 



I 191 minidisk for the IVPM 1 user 



I 191 minidisk for the IVPM2 user 



3 1 


1 


1 191 minidisk for the REM2780 user 


4-5 1 


2 


1 CP nucleus 


6 1 


1 


1 Harm start data 


7-8 ! 


2 


i I/O Error Recording area 


9-28 1 


20 


1 Spooling and paging space 


29 1 


1 


1 191 minidisk for the CPGEN user 



30-105 I 76 I 190 minidisk (the CMS system disk) for the 

I I CMSSYS user 

I I 

I I Kote: The last cylinder of the 190 minidisk 

I I (105) contains the CMS nucleus. 



106-149 I 44 I 194 minidisk of the CPGEN user - it contains 
I I the CP object modules (text decks) 



150-403 I 254 | Hot used. 
I I 

Figure 19. Format of a 3330 Restored Disk 



Figure 19 represents the allocation of areas on a 3330 starter system 
volume. 

CPGEN, CMSSYS, IVPMI, IVPM2, and REM2780 are user identifications 
that own certain minidisks on the starter system volume. 

CPGEN is the userid of the operator (that is, you use this userid to 
control the real system and to build a version of CP tailored to your 
installation. 

CMSSYS is a directory entry on the starter system volume that owns 
CMSSYS 190 (the CMS system disk). CPGEN has a read-only link to CMSSYS 
190 in order to use it to create the new system. Using this link, the 
CPGEN user can read from, but not write on, the 190 minidisk belonging 
to the CMSSYS user. 

IVPMI and IVPM2 are used with the Installation Verification Procedure 
to test the new system. 

REM2780 is used to test the 2780 as a remote entry station. 

SPECIAL CONSIDERATIONS FOR 800 BPI TAPES 

If you ordered the starter system on 800 bpi tape, you have two tapes. 
If you have two tape drives available for the system generation 
procedure, use the following form of the INPUT statement: 
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input 280 2400 281 

In this case, when DDE finishes reading the first tape volume, it issues 
the message: 

END OF VOLUME CYL XXX HD XX, MOUNT NEXT TAPE 

and continues by reading the tape mounted on the alternate tape drive 
(281). If you have only one tape drive available, you enter an INPUT 
statement in the form: 

input 280 2400 

When the end-of-volume message appears, you must demount the first tape, 
mount the second tape on the same device and ready the device. Then, 
the DASD Dump Restore program continues by reading the second tape. 



STEP 6. IPL THE STARTER SYSTEM 

You now load (IPL) the starter system from the disk you restored it to. 
In our example, you press the Load pushbutton with the load unit address 
dials set to 351. At this point, only the device containing the system 
residence volume, 351, is known to the starter system. 



STEP 7. DEFINE THE DEVICES MMM IQ. DO THE SYSTEM GENERATION 

If your system console is at an address other than 009 or OIF, after you 
load the starter system you must press the Request key (or equivalent 
key) to enable the starter system to recognize the system console. If 
the console is not recognized, the VM/370 starter system enters a wait 
state. 

At this point both the system residence volume and system console are 
recognized by the starter system and you can define the ether devices 
you need. The starter system supports up to 16 channels, 8 control 
units, and 16 devices. The real control blocks for these devices are not 
built in the standard manner; the starter system builds them 
dynamically. 

The starter system program (DMKSSP) then prompts you to answer the 
following questions until all the real control blocks necessary to 
operate a minimum machine configuration are created. The following 
example assumes: a 1403 printer at address OOE, a 2540 card reader/punch 
at addresses OOC (reader) and OOD (punch) , tape drives at addresses 280 
and 281, and a 3330 DASD at address 350. You must respond to the 
message 

ENTER DEVICE ADDRESS WHERE SYSTEM RESPONSE WILL BE BUILT (CUU) : 

with the same device address you specified on the SYSRES operand of the 
SYSRES macro in your system control file (DMKSYS) . 

If you are doing the system generation in a virtual machine, you must 
respond "no" to the message: 
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I CHANGE TOD CLOCK (YES | NO) : 

I You must also respond to messages to set the date and time. If you 

I are using a 3270 display device to generate VM/370 from the starter 

j system for the first time, the 3270 locks when you try to respond to the 

I message 

I SET DATE MM/DD/YY: 

I The System Available and Input Inhibited lights are on. You must press 

I the Reset key and move the cursor to the second position of the input 

I area before responding to the message. You follow this procedure only 

I the first time the system is defined. 

When asked what kind of start this is, you must respond "cold". The 
messages you receive at this time are: 

VM/370 STARTER SYSTEM VERSION 2.0 

ENTER PRINTER ADDRESS (CUO):00e 

ENTER DEVICE TYPE (1403, 1U43, 32 1 1) : 1 403 

ENTER PUNCH ADDRESS (CDU) : OOd 

ENTER DEVICE TYPE (2540P, 3525) : 2540p 

ENTER READER ADDRESS (COU) : OOc 

ENTER DEVICE TYPE (250 1 , 25aOR, 3505) : 25a0r 

ENTER ADDRESS WHERE PID TAPE IS MOUNTED (CUU):280 

ENTER DEVICE TYPE (240 1 , 24 15, 2420, 3420) : 240 1 

ENTER ADDRESS WHERE SCRATCH TAPE IS MOUNTED (CUU):281 

ENTER DEVICE TYPE (240 1 , 24 15, 2420, 3420) : 240 1 

ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (CUU) :350 

ENTER DEVICE TYPE (2319, 23 14, 3330, 2305) : 3330 

♦♦♦SYSTEM DEFINITION COMPLETED^^^ 

OOE PRINTER 

OOD PUNCH 

OOC READER 

280 PID TAPE 

281 SCRATCH TAPE 

350 NEW SYSTEM RESIDENCE 

ARE THE ABOVE ENTRIES CORRECT (YES,NO):yes 

VM/370 VERSION vv LEVEL PLC 0000; mm/dd/yy hh:mm:ss 

NOW 08:54:23 EDT FRIDAY mm/dd/yy 

CHANGE TOD CLOCK (YES|NO):yes 

SET DATE MM/DD/YY :mm/dd/yy 

SET TIME HH:MM:SS :09:04:36 

PRESS "TOD ENABLE SET" KEY AT DESIGNATED INSTANT 

NOW 09:04:36 EDT FRIDAY mm/dd/yy 

CHANGE TOD CLOCK (YES | NO) :no 

09:04:38 START ((COLD|WARM) (DRAIN) ) | (SHUTDOWN) :cold 

09:04:40 

09:04:42 LOGON AT 09:04:37 EDT FRIDAY mm/dd/yy 

LINE OIF LOGON AS CPGEN USERS= 001 

09:04:42 

DMKCPI952I nnnnK SYSTEM STORAGE 

If you have not defined your system residence volume with a label of 

I VMREL2, two messages indicating that the volume labeled VMREL2 is not 

mounted are issued. If you have labeled it as VMREL2, a message 

indicating VMREL2 conflict is issued. You can ignore the following 

messages. 
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09:04:43 FILES: NO RDR, NO PRT, NO PUN 
09:04:44 

DMKIOG556I FORMATTING I/O ERROR RECORDING MASK 

09:04:46 

DMKIOG557I FORMATTING MCH ERROR RECORDING AREA 

The TOD clock referred to is the System/370 Time of Day clock. Enter 
the actual date and time in response to the "SET DATE" and "SET TIME" 
messages, and press the TOD Enable Set switch on the system control 
panel when the exact time specified agrees with the installation wall 
clock. 

If, for some reason, you must reload the starter system, the 
following message is displayed: 

VM/370 STARTER SYSTEM VERSION 2.0 

DO YOU WISH TO RE-DEFINE YOUR SYSTEM (YES |N0) : 

Respond by entering "no", unless the failure was the result of 
incorrectly specifying the device addresses, or unless the tapes and/or 
disks have been moved. If you reply "yes", you repeat Step 7. 



STEP 8. SET THE TERMINAL MODE AND SPOOL THE CONSOLE 

If the system console you are using is a display device, you should at 
this point, spool your console output so that you have a record of what 
you do. To spool the console input and output, issue the command: 

spool console start 

to save a copy of the system generation. 

Because the default terminal environment for the primary system 
operator is CP, you should also issue the command: 

terminal mode vm 

The virtual machine terminal mode lets you remain in the CMS 
environment when you enter data on the display device. 



STEP 9. DEFINE OR ATI^CH THE SYSTEM RESIDENCE DEVICE 

The CPGEN virtual machine assumes that the system residence volume is 
labeled VMREL2 and is at virtual address 350 if the device type is 3330 
or at virtual address 351 if the device type is 2314. If you labeled 
your system residence volume VMREL2 in Step 2 and designated 350 at its 
virtual address in Step 7, your system residence device is already 
available. 

If you did not label your system residence device VMREL2, you must 
now attach it to your virtual machine, CPGEN. Use Procedure 2 to attach 
your system residence devices. 

For example, if you designated the 131 drive, labeled VMREL2, as your 
system residence device for the generation procedure in Step 7, now you 
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must define your virtual device 350 so that it corresponds to the real 
disk 131. 

Use one of the following procedures to define or attach your system 
residence volume; 

• Procedure 1 

If you labeled your system residence volume VMBEL2, but did not 
define its address as 350, you must do so now. Press the Request key 
and enter the command: 

define 350 as 131 

You, as the operator of the CPGEN virtual machine, gain ownership of 
that entire volume as virtual address 350. The CP DEFINE command 
maps this virtual address to the real address of your residence 
volume as defined in your DMKSYS module. 

Remember that you restored your starter system tape to a 3330 device. 
If you are now creating a 231U system residence, with label VMREL2, 
issue the command: 

define 351 as 131 

You cannot create a 3340 system residence directly from a 3330 
starter system. However, a 3340 starter system is provided and a 
procedure for generating a 3340 system residence volume from a 
current 2314 or 3330 system residence volume and a PLC tape is 
described in Appendix H. VM/370 recommends that you use the 3340 
starter system. 

• Procedure 2 

If you did not label your system residence volume as VMREL2, you must 
now attach your system residence volume to your virtual machine. 
Press the Request key and enter the command: 

attach 350 to cpgen as 350 



— , - - "^ a 



the second device address is for the virtual device. The real 350 is 
the system residence volume you formatted in Step 2. The virtual 350 
is the system residence device defined in DMKSYS (with the SYSRES 
macro) and also entered in response to the message: 

ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE HILL BE BUILT (COO) : 



STEP JO. MAKE OTHER DEVICES AVAILABLE 

You must attach your tape drives and designate the printer to receive 
abnormal termination dumps if they occur. Press the Request key to 
enter each of the following commands: 

attach 280 to cpgen as 181 
attach 281 to cpgen as 182 
set dump OOe 

In the first command, the real tape drive (280) attached must be the 
same real address you entered in Step 7 in response to the message: 

ENTER ADDRESS WHERE PID TAPE IS MOUNTED (CUU) : 
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This real device lust be attached to CPGEN as 181, because the VMFBLD 
EXEC procedure (which is used later) expects it to be 181. 

In the second command, the real tape drive (281) attached must be the 
same real address you entered in Step 7 in response to the message: 

ENTER ADDRESS WHERE SCRATCH TAPE IS MOUNTED (CUU) : 

This real device must be attached to CPGEN as 182, because the GENERATE 
EXEC procedure (which is used later) expects it to be 182. 

If only one tape drive is available, enter 

attach 280 to cpgen as 181 

You can define your virtual 181 as 182 later in the system generation 
procedure. 

The address of the real printer, defined in Step 7, is OOE. Any 
system dumps that occur are directed to that address. 

If you wish, you can issue the CP command: 

query virtual all 

before and after performing Step 10, to see how your virtual machine's 
configuration changes. 



STEP 11. LOAD CMS 

Next, you must load CMS from virtual address 190 by issuing the CP 
command : 

ipl 190 

After CMS is loaded, a message is displayed on the system console 
indicating that CMS has successfully loaded: 

CMS VERSION 2.0 mm/dd/yy hh.mm 

Press the Return key and the CPGEN 191 minidisk is accessed as your 
A-disk. 



STEP 12. LOAD THE PLC (PROGRAM LEVEL CHANGE) TAPE 

Demount the PID (Program Information Department) starter system tape, 
and mount and ready the PLC tape at 280. 

The PLC tape is prepared by the VM/370 Program Level Change (PLC) 
service. This is a system update service that can include new functions 
as well as cumulative system changes. The latest PLC tape contains all 
new updates, as well as all previous updates since the last VM/370 
release base. IBM Field Engineering is responsible for initially 
ordering the PLC service. Thereafter, PID automatically ships the PLC 
tapes to the FE location, and FE is responsible for applying the updates 
to VM/370 systems. 

The PLC tape supplied with the starter system should be installed as 
part of the system generation procedure. Issue the CMS command: 
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tape load 

The system issues the following messages: 

LOADING 

VMFBLD EXEC A1 
END-OF-FILE OR END-OF-TAPE 



The VMFBLD EXEC procedure is a service program that adds or replaces 
CP, CHS, or RSCS object modules. It loads the updates from the PLC tape 
for you. Issue the command: 

access 191 c 

because VMFBLD accesses other disks as its A-disk during processing. 
Next, issue the command: 

vmfbld cp 

to execute VMFBLD. 

The VMFBLD EXEC prompts you with the message: 

ENTER CP STAGING AREA DISK ADDRESS: 
19U 

You respond with 194. The 194 minidisk belongs to the CPGEN virtual 
machine and is the area on the restored starter system volume that 
contains all the object modules necessary to generate a CP nucleus. The 
contents of the minidisk are updated with the latest versions of all 
object modules, as well as the latest version of the DMKMAC macro 
library. The following message is displayed: 

ARE YOU A HEW USER? -- RESPOND (YES|NO) 

You must respond "yes" to this question. The following messages are 
then displayed: 

' 190" REPLACES 'A (194) • 
190 ALSO = S-DISK 
hh:mm:ss REWIND COMPLETE 
I CMS VERSION v.O - mm/dd/yy hh.mm 

The VMFBLD EXEC procedure links to the CMS system disk and accesses 

it as the A-disk. Next, VMFBLD reads the updated service programs from 

I the PLC tape and writes them to the CMS S-disk. Then VMFBLD loads the 

I new CMS system onto the system disk. After CMS is loaded, a message is 

I displayed to indicate that the CMS system was successfully loaded: 

I CMS VERSION v.O - mm/dd/yy hh.mm 

I You must enter a null line to continue. 
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STEP 13. PUNCH THE SERVICE PROGRAMS 

Use the GENERATE EXEC procedure to punch the service programs. Issue 
the command : 

generate srvcpgm 

These service programs are needed for standalone use; you should 
externally identify the decks and keep them intact. 

The programs punched are: 

• DMKFMT (A three-card loader precedes the DMKFMT text deck) 

• DMKDIR (A three-card loader precedes the DMKDIR text deck) 

• DMKDDR (A three-card loader precedes the DMKDDR text deck) 

• IBCDASDI (The IBCDASDI text deck is loadable) 

The GENERATE EXEC issues the following message: 

THE FOLLOHIHG STANDALONE SERVICE PROGRAMS ARE BEING PUNCHED 
** FORMAT - DIRECT - DUMP/RESTORE - IBCDASDI ** 

PUNCHING • IPL FMT • ♦*♦♦♦♦ 

PUNCHING ' IPL DIR • ****** 

PUNCHING • IPL DDR ' ****** 

PUNCHING ' IPL IBCDASDI • ****** 

Each program deck is preceded by a CP userid card and several 
separator cards, all of which may be discarded. The format of these 
cards is described in the yM/370: Operator's Guide. 

For more information about the GENERATE EXEC procedure, see "Part 6: 
Updating VM/370." 



STEP JiJ. PRINT AND PUNCH THE STARTER SYSTEM SUPPLIED DIRECTORY, DMKSNT, 
DMKSYS, AND DMKFCB 

After the service programs are punched, the GENERATE EXEC asks you 
whether you want a copy of the Release 2 directory printed. You should 
respond "yes." 

PRINT COPY OF RELEASE2 DIRECT? ~ RESPOND (YES | NO): yes 

This prints a copy of the Release 2 directory, as well as copies of the 
DMKSYS ASSEMBLE (the system definition file) , DMKFCB ASSEMBLE (the forms 
control buffer file) , and DMKSNT ASSEMBLE (the system name table) 
provided with the starter system. 

The GENERATE EXEC procedure issues the following message: 

A SAMPLE DIRECTORY IS BEING PRINTED TO AID YOU. 

IT SHOWS WHERE THE VIRTUAL DISKS ARE LOCATED ON •CPV2L0' 

YOU MAY USE THESE MINIDISKS FOR OTHER VIRTUAL MACHINES, 

IN PARTICULAR THE CMS SYSTEM DISK ( MAINT 190 ) AND 

THE CP STAGING AREA DISK ( MAINT 194 ) 

INCLUDED IN THIS DIRECTORY IS THE USERID: MAINT 

WHICH WILL BE USED FOR FUTURE SUPPORT OF THE SYSTEM. 
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THIS USERID SHOULD BE INCLUDED IN THE DIRECTORY 
YOU BUILD FOE YOUR FLOOR USE. 

** CAUTION ♦* IF YOU DESTROY USER MAINT'S AREAS, IT WILL BE 
NECESSARY TO RE-BUILD THE ENTIRE SYSTEM. 

A SAMPLE OF DMKSYS, DMKFCB, AND DMKSNT ASSEMBLE ARE ALSO BEING 
PRINTED TO AID YOU. THIS SAMPLE DMKSNT IS BASED ON THE 
INFORMATION INCLUDED IN THE SAMPLE DMKSYS AS WELL AS THE 
EXAMPLE ALLOCATIONS FOR yHREL2 PROVIDED IN THE SYSGEN GUIDE. 
A COPY OF THIS DMKSNT MODULE HAS BEEN INCLUDED IN THE CP NUCLEUS, 
SUCH THAT IF ONE USES THE INCLUDED DMKSYS AND THE 
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SAMPLE ALLOCATION PROVIDED IN THE SYSTEM GENERATION GUIDE, 

HE WILL BE ABLE TO SAVE HIS CMS SYSTEM UPON COMPLETION 

OF THE SYSTEM GENERATION PROCEDURE. A COPY OF DMKFCB HAS BEEN 

INCLUDED IN THE NUCLEUS AND NEED NOT BE RE-ASSEMBLED FOR 

SYSTEM GENERATION. IT HAS BEEN INCLUDED FOR THE USER WHO WOULD LIKE 

TO MODIFY OR ADD TO THE EXISTING BUFFER LOAD. 

NOTE: IF THE USER WISHES TO MODIFY THE SAMPLE DMKSNT AND/OR DMKFCB 
HE MAY INCLUDE THE UPDATED SOURCE WITH THE SOURCE INCLUDED UNDER 
THE OPTION 'GENERATE VM370', OF THE SYSTEM GENERATION PROCEDURE. 
IF PRESENT, IT WILL AUTOMATICALLY BE ASSEMBLED AND INCLUDED IN THE 
NEW CP NUCLEUS. 

Again, the GENERATE EXEC procedure prompts you: 

DO YOU WISH TO HAVE A COPY OF DMKSNT, DMKSYS, DMKFCB, AND 
RELEASE2 DIRECT PUNCHED TO CARDS? — RESPOND (YES | NO) : 

I You should enter "yes" to have these decks punched. "Part 2: Defining 
I Your VM/370 System" contains a listing of the Release 2 VM/370 directory 
I and the DMKSNT, DMKSYS, and DMKFCB modules supplied with the starter 
I system. The following messages are issued to indicate the files that 
are being punched: 

PUNCHING • DMKSNT ASSEMBLE • ****** 

PUNCHING • DMKSYS ASSEMBLE • ****** 

PUNCHING • DMKFCB ASSEMBLE • ****** 

PUNCHING • RELEASE2 DIRECT • ****** 

R; 



STEP 15. BUILD THE VM/370 DIRECTORY AND ASSEMBLE THE FILES DEFINING THE 
REAL I/O AND SYSTEM DEVICES 

Next, you should place the files describing your installation's version 
of the VM/370 directory, real I/O configuration, and system devices in 
the reader and invoke the GENERATE EXEC procedure to build the directory 
and assemble the files describing the configuration. Place the 
following cards in the card reader, in the seguence shown: 

ID CPGEN 

:READ filename DIRECT 

(Directory program control statements) 

:READ DMKRIO ASSEMBLE 

(real I/C configuration macros) 

:READ DMKSYS ASSEMBLE 

(CP system control file macros) 

The Directory program control statements, real I/O configuration macros, 
and CP system control file macros are those you created according to the 
instructions in "Part 2: Defining Your VM/370 System." 

Also, if you want, you can change the printer buffer load (DMKFCB) or 
the named system (DMKSNT) modules to conform to local requirements. If 
you want to' change the printer buffer load or the system name table, you 
should add your changes to the files already punched (in Step 14) and 
place the following files in the card reader behind the CP system 
control file macros: 

Part 3: Generating VM/370 (CP, CMS, and RSCS) 193 



3330 Starter System 



:READ DHKFCB ASSEMBLE 
(forms control macros) 
:READ DHKSNT ASSEMBLE 
(system name table macros) 



Instructions for creating new forms control macros are in the VM^370: 
System Programmer j_s Guide. The system name table macros are described 
in "Part 2: Defining Your VM/370 System" of this manual. 



FORMAT OF THE READ COMTROL STATEMENT 



The READ control statements must be punched according to the following 
format. 





Number 


of 


1 










Column 


Charact 


ers 


IConten 


ts 


Meaning 






1 


1 




|colon« 


• 


Identifies card 


as a 


control card 


2-5 


4 




1 
IREAD 




Identifies card 


as a 


READ control card 


6-7 


2 




1 

1 blank 










8-15 


8 




1 

1 f name' 




Filename of the 


file 


punched 


16 


1 




1 
(blank 










17-24 


8 




1 

If type 

1 




Filetype of the 


file 


punched 


25-80 


56 




1 
{blank 











SPECIAL PROCEDURE IF YOU ARE USING ONLY ONE TAPE DRIVE 



If you are using only one tape drive, at this time you must issue the 
command : 

define 181 as 182 

Now mount the scratch tape in place of the PLC tape and ready the 
device. 



INVOKE THE GENERATE EXEC PROCEDURE 



When all the files are placed in the reader, invoke the GENERATE EXEC 
procedure by issuing the following command: 

generate vm370 

This procedure invokes the Directory service program to build the 
disk-resident VM/370 directory, then assembles the DMKRIC and DMKSYS 
files that you placed in the real card reader. After the Directory 
service program execution completes, the DMKRIO and DMKSYS files are 
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assembled in preparation for building the new CP system nucleus. 
GENERATE then checks for DMKFCB and DHKSNT source files. When new 
versions of the DMKFCB and DMKSNT modules are provided, GENERATE 
assembles the new modules and replaces the corresponding modules 
supplied with the starter system with the new moduleSi If any errors 
occur while the VM/370 directory is being built, the Directory program 
issues error messages and the GENERATE EXEC procedure issues the 
following message: 

CORRECT THE DIRECTORY CARDS AND RELOAD THE CARD HEADER 
RESPOND WITH: GENERATE DIRECT 

Correct the errors in the Directory program control statements, and 
reload the card reader with only the ID card, the :READ statement, and 
the Directory program control statements. Then respond with: 

generate direct 

If errors are detected while the DMKRIO, DMKSYS, DMKFCB, or DMKSNT 
files are assembling, GENERATE issues a similar message: 

CORRECT THE filename ASSEMBLE FILE AND RELOAD THE CARD READER 
RESPOND WITH: GENERATE filename 

You must correct the errors in the indicated file, and reload the card 

reader with only the ID card, the :READ statement, and the appropriate 

file. Then, issue the GENERATE command with the appropriate option. 
For example: 

generate dmksys 



STEP 16. SPECIAL CONSIDERATIONS FOR VIRTUAL=REAL MACHINES 

Once the directory is built and the files are assembled, the GENERATE 
EXEC procedure asks if you want the virtual=real option included in your 
CP nucleus: 



If you respond "yes" to this guestion, you are prompted to enter the 
amount of storage you wish to reserve in the CP nucleus for a 
virtual=real machine. ("Part 1. Planning for System Generation" 
contains formulas to help you determine how much storage you need to 
reserve.) This size must be a multiple of 4K and must be entered in the 
format nnnnK. The minimum size you can specify is 32K and the maximum 
is 4M. For example: 

STORAGE SIZE OF VIRT=REAL (MINIMUM IS 32K) : 

100k 

0100K STORAGE SIZE FOR VIRTUAL=REAL 

IS THE ABOVE ENTRY CORRECT (YES, NO) : 

yes 



I STEP J7. LOAD THE CP NUCLEUS 

I Once you respond to the virtual=real generation questions, the GENERATE 
I EXEC procedure writes the CP nucleus on tape. To do this, GENERATE 
I first issues the VMFLOAD command to punch the loader and CP object 
I modules to a virtual punch spool file. Then it transfers this file to 
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I the virtual card reader file and writes the file on tape. GENERATE 

I issues the following messages during the processing: 

I hh:mm:ss MO FILES PURGED 

I SYSTEM LCAD DECK COMPLETE 

I hh:mm:ss PUN FILE nnnn TO CPGEN COPY 01 NOHOLD 

I IPLABLE NUCLEUS NOW ON TAPE ♦♦** 

I hh:mi:ss PRT cuu OUTPUT OF CPGEN FILE=nnnn RECDS=nnnnnn 

I COPY = 01 A PRT 

I Note: If any errors are detected while the tape is being written, you 

I must recreate the CP nucleus. To do this, issue the command: 

I generate cp nucleus 

I The procedure restarts at Step 16 where you are asked if you want the 

I virtual=real option. 



I LOADING A CP NUCLEUS WITHOUT A VIRTUAL=REAL AREA 

I If you respond "no" when asked if you wanted the virtual=real area, the 
I GENERATE EXEC procedure loads the nucleus for you. You receive the 
I following message: 

I WHEN 'NUCLEUS LOADED ON XXXXXX* IS TYPED, ISSUE 'CLOSE PRT', 
I TO GET THE CPLOAD MAP. WHEN PRINTING IS COMPLETE, 
I SHUTDOWN THE SYSTEM AND IPL THE NEW SYSRES VOLUME. 

I When the nucleus is written on the system residence volume, the message 

I NUCLEUS LOADED ON volid 

I is issued, where volid is the volume serial number of your system 
I residence volume. The volid is the serial number you specified on the 
I SYSRES macro when you prepared the CP system control file (DMKSYS) . If 
I you followed the example in this manual, the serial number of your 
I system residence volume is VMREL2. 

j To print the load map you must close the printer; issue the command: 

I close prt 

I When printing is complete, shutdown the system in preparation for 
I loading your newly generated CP nucleus: 

I shutdown 



I LOADING A CP NUCLEUS THAT HAS A VIRTUAL=REAL AREA 

I If you responded "yes" when asked if you wanted the virtual=real area, 

I the GENERATE EXEC procedure issues the following message: 

I TO LOAD THE CP NUCLEUS JUST CREATED, SHUTDOWN THE SYSTEM AND 
I THEN IPL THE TAPE. THE CPLOAD MAP WILL AUTOMATICALLY BE PRINTED AT THE 
I PRINTER WHOSE ADDRESS IS 'OOE'. IF THERE IS NO PRINTER AT THIS ADDRESS 
I THE LOAD MAP WILL BE PRINTED AT THE FIRST PRINTER CAUSING AN INTERRUPT 
I (IE. NOT-READY TO READY SEQUENCE) . ONCE THE NUCLEUS HAS BEEN LOADED, 
I YOU MAY IPL YOUR NEW CP SYSTEM RESIDENCE VOLUME. 
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NOTE: THERE MUST BE ENOUGH STORAGE ON THE SYSTEM (VIRTUAL OR REAL) , TO 
CONTAIN THE VIRT=REAL AREA AND THE CP NOCLEDS. 

You must be sure that there is enough storage to load the CP nucleus 
with a virtual=real area before you load it. The "Specifying a 
Virtual=Real Machine" section of Part 1 tells you how to determine the 
amount of real or virtual storage you need. You can load a CP nucleus 
that has a virtual=real area in either a real or virtual machine. 

You IPL the tape containing the CP nucleus next. The CP nucleus is 
on the tape at virtual address 182 for the CPGEN virtual machine. 



STEP 18. IPL THE NEWLY GENERATED VM/370 

IPL the newly generated system residence volume by setting the load unit 
address dials to the address of the system residence volume and pressing 
the Load pushbutton. The userid OPERATOR (or whatever userid you 
specified as the system operator on the SYSOPER macro) is logged on when 
you IPL. The following messages are issued. Respond as shown. 

VM/370 VERSION vv LEVEL 00 PLC nnnn; mm/dd/yy hh:mm:ss 

NON hh:mm:ss EDT day mm/dd/yy 

CHANGE TOD CLOCK (YES|NO):no 

hh:mm:ss START ((COLDjWARN) (DRAIN) ) | (SHUTDOWN) : cold 

hh:mm:ss LOGON AT hh:mm:ss EDT day mm/dd/yy 

hh:mm:ss LINE OIF LOGON AS OPERATOR USERS = 001 

hh:mm:ss 

DMKCPI952I nnnnK SYSTEM STORAGE 

hh:mm:ss FILES: NO RDR, NO PRT, NO PUN 
hh:mm:ss 

DMKI0G556I FORMATTING I/O ERROR RECORDING AREA 

hh:mm:ss 

DMKI0G557I FORMATTING MCH ERROR RECORDING AREA 

At the time you IPL your newly generated VM/370, your system 
residence is formatted according to your specification on the SYSRES 
macro. Also, if you used the VM/370 directory supplied with the 3330 
starter system, your starter system volume (CPV2L0) is set up as shown 
in Figure 20. Be careful not to modify the 190 and 19U minidisks for 
the MAINT user. These minidisks, and the information they contain, are 
required for applying PLC (Program Level Change) updates to VM/370, 
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1 Real 1 Number of | 

1 Cylinder | Cylinders | Contents 


1 1 1 1 Unused 


1 1 1 1 1 191 minidisk for the IVPM1 user 


1 2 1 1 1 191 minidisk for the IVPM2 user 


1 3 1 1 1 191 minidisk for the REH2780 user 


1 4-10 1 7 1 191 minidisk for the OPERATOR user 


1 11-15 1 5 1 191 minidisk for the CE user 


1 16-22 1 7 1 191 minidisk for the MAINT user 


1 23-28 1 6 1 191 minidisk for the ECMODE user 


1 29 1 1 1 199 minidisk for the MAINT user 


1 30-105 1 76 1 190 minidisk for the BAINT user 

1 1 1 Note: The last cylinder of this minidisk 
1 1 1 contains the CHS nucleus. 


1 106-149 1 44 1 194 minidisk for the HAINT user 


1 150-403 1 254 | Not used. 



Figure 20. Allocation of the Starter System Volume (CPV2L0) When the 
3330 Starter System Directory Is Used 



STEP 19. BACK OP THE NEWLY GENERATED VM^370 



At this time, you should be sure to back up your new system residence 
volume. If your real machine has at least 448K bytes of real storage, 
the tape created in Step 17 is sufficient backup. However, that tape is 
not sufficent backup for real systems with less than 448K of real 
storage because that tape cannot be loaded on such systems. 

VM/370 systems that execute on a real machine with less than 448K 
bytes of real storage should use the DASD Dump Restore (DDR) service 
program to create a backup tape similar to the one created in Step 17. 
The DASD dump restore program is described in Appendix F. If your 
system residence voluiqe is at address 350 and you labeled it VHREL2, you 
could use the following DDR control statements to back it up: 

input 350 3330 vmrel2 
output 180 3420 
dump cpvol 

The tape produced contains the CP nucleus; it does not contain the 
VH/370 directory. However, you already created a standalone version of 
the Directory program in Step 13 and have the Directory program control 
statements, which you used in Step 15, to recreate the VM/370 
directory. 

If you do not wish to use the DDR program to tack up your system, you 
can load the tape produced in Step 17 in a virtual machine. If you load 
the tape in a virtual machine, that virtual machine must have (1) 512K 
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I of storage and (2) write-access to the system residence volume, at the 

I address defined for system residence in the SYSRES macro of the CP 

I System Control (DMKSYS) file. 

! Hhen you use the DDE program to hack up your system you do not get a 

I load map when you restore the tape. You do get a load map if you load 

I the tape produced in Step 17. 



STEP 20. MOVE THE CMS SYSTEM DISK, IF YOU WISH 

The CP nucleus just created is tailored to your installation's exact I/O 
configuration with all the appropriate options selected. The CMS nucleus 
requires no special tailoring for installation. The CMS system residence 
disk was created when the VM^370 starter system was loaded^ it contains 
a copy of the CMS nucleus and disk-resident command modules. At this 
point, the CMS system resides on the virtual 190 disk for the user, 
MAIUT. The operator's VM/370 directory has an entry that links to 
MAINT's 190 disk, therefore you can invoke CMS by issuing the command: 

ipl 190 

I and thus have access to most of the CMS functions. Although most of the 
I CMS functions are available, CMS has not yet been updated with the 
I latest PLC changes. The Assembler that is available now is the one 
I supplied with the starter system. 

If you wish, you can move the CMS system disk to a disk other than 
the one designated by the starter system. To move the CMS system disk 
to another minidisk, use the COPY function of the DDE service program. 
The new minidisk should be the same size as the CMS system disk, but it 
does not need to be formatted. Also, if you move the CMS system, you 
must make the appropriate changes to the userid MAINT in your VM/370 
directory (that is, change the MDISK entry for 190) . 

If you add IBM Program Products or your own disk-resident modules to 
the CMS system disk, you may have to create a new system disk to contain 
the additional modules. The "Creating a CMS System Disk" section of 



STEP 2J. FORMAT THE OPERATORJ_S VIRTUAL J91 DISK 

\ 

Before any new minidisk area can be used for CMS files, it must be 
initialized with the CMS FORMAT command, which formats the area into 
800-byte blocks. Take care not to format areas which contain data 
restored from the starter system (such as the 190 and 194 minidisks 
belonging to the user MAINT.) The CMS FORMAT command is described in 
the VM/370 : Command Lan3]i§3§ Guide for General Users. 

Note; After you complete this step, a portion of the starter system is 
overlaid by the operator's virtual 191 minidisk. If for any reason you 
wish to IPL the starter system again, you must restart at step 1. 

At this time you are logged on as the operator. Use the following 
procedure to format your virtual disk 191. First, load CMS (IPL 190). 
CMS responds with: 

CMS VERSION 2.0 - mm/dd/yy hh:mm 
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Hext , enter the following command: 

access (nodisk 

The MODISK option prevents CMS from automatically accessing your virtual 
disk 191. (Accessing 191 at this time would cause an error message to be 
issued, because 191 is not yet initialized, and therefore cannot be 
used.) After the Ready message is displayed, issue the command: 

format 191 a 

The CMS FORMAT command prompts you with the following message: 

FORMAT WILL ERASE ALL FILES ON DISK *k{^9^)*. DO YOU HI SH TO 
CONTINUE? (YESINO) : 

If you respond yes, CMS prompts you with: 

ENTER DISK LABEL: 
opr191 

Enter the one- to six-character alphameric label of the virtual disk. 
You can use whatever label you wish for this virtual disk. In this 
example, the label is 0PR191. CMS then issues: 

FORMATTING DISK 'A'. 

•07» CYLINDERS FORMATTED ON 'A (191)'. 

and a Ready message. 



STEP 22. FORMAT THE MAI NT DSERIS VIRTUAL 191 DISK 

Next, you should initialize the 191 disk belonging to MAINT, in the same 
way you initialized the operator's 191. Log yourself off the system and 
log on again as userid MAINT, using the password CPCMS. Now IPL 190. 
When the CMS Ready message is displayed, issue 

access (nodisk 

and continue to format MAINT 's 191, using the same procedure you used to 
format 0PR191. 



STEP 23. UPDATE CMS 

Now that the MAINT 191 minidisk is formatted, you (as the MAINT user) 
can update CMS with the changes supplied on the PLC tape. Mount the PLC 
tape, if it is not already mounted. You must attach the real tape drive 
to your CMS virtual machine (MAINT) ; for example: 

attach 280 to maint as 181 

and, with the 191 minidisk that belongs to MAINT accessed as your 
A-disk, rewind and load the tape: 

tape rew 
tape load 
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CMS responds with the following message 



LOADING, 
VMFBLD 



EXEC 



■D »T n <-. : 



T5 T T « 



ji«u — ur — r X AiJi «jn £iau — yjj: — ± tie s, 



BUILDING A NEW CMS 



Now execute the VMFBLD EXEC crocedure bv issuina the commands: 



access 191 c 
vmfbld cms 

The VMFBLD EXEC procedure prompts you with: 

ENTER CMS SYSTEM DISK ADDRESS: 
You respond with "190". Next, VMFBLD issues the message: 

190 ALSO = S-DISK. 
You are asked if you want the service programs punched: 

PUNCH STANDALONE SERVICE PROGRAMS — RESPOND (YES|NO): 

The following messages are displayed; respond as shown: 

hh:mm:ss NO FILES PURGED 

hh:mm:ss NO FILES PURGED 

SYSTEM LOAD DECK COMPLETE 

hh:mm:ss PUN FILE nnnn TO CPGEN COPY 01 NOHOLD 

hh:mm:ss REWIND COMPLETE 

WHEN THE NEW CMS SYSTEM IS BUILT ISSUE THE FOLLOWING 

COMMAND 

CLOSE PRT . . . (PRINTS THE LOAD MAP) 

DMSINI606R SYSTEM DISK ADDRESS = 190 
DMSINI615R Y-DISK ADDRESS = 1 9e 
DMSIHI607R REWRITE THE NUCLEUS ? yes 
DMSINI608R IPL DEVICE ADDRESS = 190 
DMSINI609R NUCLEUS CYL ADDRESS = 75 
DMSINI610R ALSO IPL CYLINDER ? yes 
DMSINI611R VERSION IDENTIFICATION = 
DMSINI612R INSTALLATION HEADING = 
CMS VERSION 2.0 - mm/dd/yy hh:mm 

In the example, the 190 you entered is the 190 minidisk that belongs 
to the user MAINT; it is equivalent to the 190 minidisk that belongs to 
CPGEN on the starter system. If you used the VM/370 directory supplied 
with the starter system, you allocated 76 cylinders (virtual cylinders 
0-75) to the 190 minidisk belonging to the user MAINT. The last cylinder 
of this minidisk contains the CMS nucleus, therefore you specify 75 as 
the nucleus cylinder address when responding to message DMSINI609R. 

When the VMFBLD EXEC procedure completes its execution, the CMS 
system residence volume is updated with the most current object modules 
(text decks) and load modules, and the new CMS nucleus is written on the 
CMS system residence volume. 

I Also, if there are any updates for the EREP program or the Assembler 
I on the PLC tape, the VMFBLD EXEC procedure updates those programs and 
I creates the corresponding auxiliary directories. 
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STEP 2a. SAVE CHS 

If you used the sample DBKSNT and DMKSYS supplied with the starter 
system, and used the sample allocations shown in Step 2, you can now 
save your CMS system. 

To save the CBS system, you must load it and then save it as soon 
after loading as possible. Issue the command: 

ipl 190 

When the terminal unlocks, do not press carriage return, but immediately 
issue the command: 

savesys cms 

Then press carriage return. If CMS is successfully saved, the message 

hh:mm:ss SYSTEM SAVED 

CMS VEBSIOH 2.0 - mm/dd/yy hh:mm 

is displayed. Your CMS system is now saved; you can issue IPL CMS 
instead of IPI 190, when you wish to run CMS. 

If you named your CMS system something other than CMS, such as CMS1, 

the entry you made in the system name table would be for CMSl, you would 

I have to save CMSl (SAVESYS CMSl) and then you could IPL CMSl. For more 

I information about how to save CMS, see the VM/370: System Pro^rammerJ^s 

I Guide or the "Saved Systems" section of this manual. 

At this point, use the Installation Verification Procedure (IVP) to 
test the new system. Log off as the userid MAIHT and log on again as 
the userid OPERATOR, using the password OPEEATGB. The IVP is described 
later in Part 3. 



202 VM/370: Planning & System Generation Guide 



3340 Starter System 
Generating CP and CMS Using the 3340 Starter System 



Except where otherwise noted, you can, if you wish, substitute other 
values in place of the device addresses, volume labels, and allocations 
shown. Note that if you use the sample DMKSNT and DMKSYS provided with 
the starter system, and use the sample allocations shown in Steps 2 and 
3, you can save your CMS system at the end of the procedure. 

The 3340 Model 35 and 3340 Model 70 starter systems are identical. If 
you create a 3340 Model 70 starter system, cylinders 349-697 are not 
used. 

It IS strongly recommended that you use the sample allocations given 
in Step 2 and the label VMREL2 for the new system residence volume, to 
ensure that you have sufficient TEMP space to complete the system 
generation. (The TEMP space provided on the starter system volume may 
not be sufficient for large systems.) 

The examples of messages and responses assume that you are performing 
the system generation at a typewriter terminal, such as a 3210, 2741, or 
3767 (operating as a 2741). If you are using a display device, such as 
the 3277, when you type the response to a prompting message that 
response appears in the user input area. When you enter that response, 
it is redisplayed in the output area on the line below the prompting 
message. Also, if the standalone service programs (such as the DASD 
Dump Restore program or Format/Allocate program) send output to a 
terminal display screen, the output is wrapped around immediately, when 
the screen becomes full, to continue displaying. 

While you are generating the system, you may see some extraneous 
messages as the starter system does its processing. These are not shown 
in the examples below. Only those messages that you should take note of 
or respond to are shown. 



i ^TcF J. LOAD THE FORMAT PROGRAM FROM THE STARTER SYSTEM TAPE 

I Mount the CP starter system tape and IPL the tape. The CP 
I Format/Allocate service program is the first file on the tape; it is now 
I loaded. Do not rewind the tape because the next file is needed later in 
I the system generation procedure (Step 4) . 



I STEP 2. FORMAT, LABII;/ hM hIih^£AlI IM SYSTEM RESIDENCE VOLUME 

I Use the CP Format/Allocate program to format, label, and allocate space 

I on the new system residence volume. First, identify the system console 

I by pressing the Reguest key (or eguivalent); if the console address is 

I either 009 or OIF, you do not have to press the Reguest key. Then, to 

I execute the Format/Allocate service program, respond to the prompting 

I messages. 

I In the following example, the responses (format, 341, 3340-35, 000, 

I 348 and VMREL2) format the 3340 disk at address 341 and label it 

I VMREL2. The values you should specify for a 3340 model 70 are shewn in 

I parentheses. Whatever label you specify must match what you specified 

I on the SYSVCL operand of the SYSRES macro when you defined the system. 
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In any case, do not use CPV2L0 because that is the label of the starter 
system disk. The console output looks like: 

VM/370 FCRMAT/ALLOCATE PROGRAM VERSION 2.0 

ENTER FORMAT OR ALLOCATE: format 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU):311 

ENTER DEVICE TYPE: 3340-35 (or, 3340-70) 

ENTER START CYLINDER (XXX) OR "LABEL": 000 

ENTER END CYLINDER (XXX) : 348 (or, 697) 

ENTER DEVICE LAEEL:vmrel2 

FORMAT STARTED 

FORMAT DONE 

000 PAGE RECORDS FLAGGED 

When the Format/Allocate operation completes, the prompting message: 

ENTER FORMAT OR ALLOCATE: 

is displayed. Now that the system residence volume is formatted and 
labeled, you must allocate the disk space. Again, you must respond to 
the prompting messages. In the following example, the space on the 3340 
disk at address 341, with the label VMREL2, is allocated (11 cylinders 
of permanent space, 5 cylinders of directory, 310 cylinders of temporary 
space, and 23 cylinders of TDSK space) . You can use the formulas given 
in the "Creating Your VM/370 Directory" section of Part 2 to ensure that 
five cylinders are enough space for your VM/37C directory. If you do 
not allocate your DASD space as shown in this example, you are 
responsible for ensuring that you have enough temporary space to perform 
the assemblies associated with VM/370 system generation. 

ENTER FORMAT OR ALLOCATE: allocate 

ALLOCATE FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 34 1 

ENTER DEVICE TYPE:3340-35 (or, 3340-70) 

ENTER DEVICE LABEL:vmrel2 

ENTER ALLOCATION DATA FOR VOLUME VMREL2 

TYPE CYL CYL 



perm 000 010 

drct Oil 015 

temp 016 325 

tdsk 326 348 

end 

ALLOCATION RESULTS 

PERM 000 010 

DRCT Oil 015 

TEMP 016 325 

TDSK 326 348 

DEVICE 341 VOLUME VMREL2 ALLOCATION ENDED 

If your system residence volume is a 3340 Model 70, the allocation 
results messages show the unused cylinders (349-697) as temporary 
space. 

Note: If you encounter I/O errors on alternate tracks, allocate the 
cylinder as permanent (PERM) space. 
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I STEP 3. LABEL THE STARTER SYSTEM VOLUME 

I Use the Format/Allocate program to label the scratch volume that is to 

i contain the CP starter system. This label must be CFv2L0. You can 

I format and label this volume, or just label it. Formatting is 

I unnecessary because you are going to restore the starter system to this 

I volume. In the following example, the responses (format, 340, 3340-35, 

I label, and cpv2l0) to the prompting messages put the label CPV2L0 on the 

I 3340 disk at address 340. 

I ENTER FORMAT OR ALLOCATE: format 

I FORMAT FUSCTION SELECTED 

I ENTER DEVICE ADDRESS (CCU) : 340 

! ENTER DEVICE TYPE:3340-35 (or, 3340-70) 

i ENTER START CYLINDER (XXX) OR "LABEL" : label 

I ENTER DEVICE LABEL: cpv210 

I LABEL IS NOW CPV2L0 

I When the Format/Allocate program is complete, it responds: 

I ENTER FORMAT OR ALLOCATE: 

I You do not have to respond to this message. 

I Now the volume is available and ready for the data that is to be 

I placed on it by the DASD Dump Restore service program (module DMKDDR) . 

I The DASD Dump Restore program is the second file on the starter system 

I tape. 



I STEP 4. LOAD THE DASD DUMP RESTORE PROGRAM PROM THE STARTER SYSTEM TAPE 

I IPL the starter system tape a second time to load the DASD Dump Restore 
I (DDR) program. It is the second file on the starter system tape. 
I Again, do not rewind the tape because the next file is needed in Step 
I 5. 



I STEP 5. RESTORE THE STARTER SYSTEM TO DISK 

I Respond to the DDR prompting messages to restore the starter system. 

I In the following example, the starter system is restored from the 

I 2400 series tape drive at address 280 to the 3340 disk at address 340 

I (and with label CPV2L0) . The console output is: 

I VM/370 DASD DUMP/RESTORE PROGRAM VERSION 2.0 

I ENTER CARD READER ADDRESS OR CONTROL STATEMENTS 

I ENTER: sysprint cuu (cuu=real printer address) 

I ENTER: input 280 2400 (See the "Special Considerations for 800 BPI Tapes" 

I section, if you ordered your starter system on 800 bpi tape) 

I ENTER: output 340 3340-35 cpv210 (or, output 340 334C-70 cpv210) 

I ENTER: restore all 

I RESTORING CPV2L0 

I END OF RESTORE 

I ENTER: (null line — END key on 3215 or Enter key on 3277) 

I END OF JOB 

I The DDR program restores the third file on the starter system tape to 

I the disk labeled CPV2L0. The restored disk contains: 
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• A VM/370 directory (RELEASE2 DIRECT) , as well as sample source for 
DMKSYS, DMKSHT, and DBKFCB 

• A VM/370 starter system nucleus 

• A complete CBS system residence volume 

• A complete CP system comprised of macro libraries and text files 

When the disk is restored, continue with the system generation 
procedure. The format of the restored disk is shown in Figure 21. 



1 .11.. .... , , . ,..,...... .. , .J „.., ,. . . ... .._.. ,. ., 

1 Real 1 Number of | 

1 Cylinder | Cylinders | Contents 


1 1 1 1 VM/370 directory 


1 1-2 1 2 1 191 minidisk for the IVPM1 user 
1 3-U 1 2 1 191 minidisk for the IVPM2 user 


1 5-6 1 2 1 191 minidisk for the HEM2780 user 
1 7-10 1 ^ 1 CP nucleus 


1 11 1 1 1 Warm start data 


1 12-13 1 2 1 I/O Error Recording area 

1 14—45 1 32 1 Spooling and paging space 

1 46-47 1 2 1 191 minidisk for the CPGEN user 


1 48-250 1 203 | 190 minidisk (the CMS system disk) for the 

1 1 1 CMSSYS user 

1 1 1 Hote: The last two cylinders of the 190 

1 1 i minidisk (249-250) contain the CMS nucleus. 


1 251-348 1 98 j 194 minidisk of the CPGEN user - it contains 
1 1 1 the CP object modules (text decks) 

1 Note: Cylinders 349—697 are not used when the starter system is 
1 restored to a 3340 Model 70, 



Figure 21, Format of a 3340 Restored Disk 



Figure 21 represents the allocation of areas on a 3340 starter system 
volume, 

CPGEN, CMSSYS, IVPMI, IVPM2, and REM2780 are user identifications 
that own certain minidisks on the starter system volume. 

CPGEN is the userid of the operator (that is, you use this userid to 
control the real system and to build a version of CP tailored to your 
installation, 

CMSSYS is a directory entry on the starter system volume that owns 
CMSSYS 190 (the CMS system disk) . CPGEN has a read-only link to CMSSYS 
190 in order to use it to create the new system, Dsing this link, the 
CPGEN user can read from, but not write on, the 190 minidisk belonging 
to the CMSSYS user. 
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I IVPM1 and IVPM2 are used with the Installation Verification Procedure 
I to test the new system. 

I DVMO'7Qn i r^ ttf^^Ji *. ^ i.^^^ 4.1.^ O *? O A -^ r^ ^ «> ^ m ^ 4. ^ ^ n 4. V n C'*.^*-i^n 



I SPECIAL CONSIDEBATIOMS FOR 800 BPI TAPES 

I If you ordered the starter system on 800 bpi tape, you have two tapes. 

I If you have two tape drives available for the system generation 

I procedure, use the following form of the INPUT statement: 

I input 280 2U00 281 

I In this case, when DDR finishes reading the first tape volume, it issues 

I the message: 

I END OF VOLUME CYL XXX HD XX, MOUNT NEXT TAPE 

I and continues by reading the tape mounted on the alternate tape drive 

I (181). If you have only one tape drive available, you enter an INPUT 

I statement in the form : 

I input 280 2U00 

I Rhen the end-of -volume message appears, you must demount the first tape, 

I mount the second tape on the same device and ready the device. Then, 

I DASD Dump Restore program continues by reading the second tape. 



I STEP 6. IPL THE STARTER SYSTEM 

I You now load (IPL) the starter system from the disk you restored it to. 
I In our example, you press the Load button with the load unit address 
I dials set to 340. At this point, only the device containing the system 
i residence volume, 340, is known to the starter system. 



I STEP 7. DEFINE THE DEVICES NEEDED TO DO THE SYSTEM GENERATION 

I If your system console is at an address other than 009 or OIF, after you 

I load the starter system you must press the Request key (or equivalent 

I key) to enable the starter system to recognize the system console. If 

I the console is not recognized, the VM/370 starter system enters a wait 

I state. 

I At this point both the system residence volume and system console are 
I recognized by the starter system and you can define the other devices 
I you need. The starter system supports up to 16 channels, 8 control 
I units, and 16 devices. The real control blocks for these devices are 
I not built in the standard manner; the starter system builds them 
I dynamically. 

I The starter system program (DMKSSP) then prompts you to answer the 
I following questions until all the real control blocks necessary to 
I operate a minimum machine configuration are created. The following 
I example assumes: a 1403 printer at address OOE, a 2540 card reader/punch 
I at addresses OOC (reader) and OOD (punch) , tape drives at addresses 280 
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and 281, and a 33U0 DASD at address 341. You must respond to the 
message 

ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BOILD (cuu) : 

with the same device address you specified on the SYSRES operand of the 
SYSRES macro in your CP system control file (DMKSYS) . 

If you are doing the system generation in a virtual machine, you must 
respond "no" to the 

CHANGE TOD CLOCK (YES|NO): 

message. 

You must also respond to messages to set the date and time. If you 

are using a 3270 display device to generate VM/370 from the starter 

system for the first time, the 3270 locks when you try to respond to the 
message 

SET DATE mm/dd/yy; 

The System Available and Input Inhibited lights are on. You must press 
the Reset key and move the cursor to the second position of the input 
area before responding to the message. You follow this procedure only 
the first time the system is defined. 

When asked what kind of start this is, you must respond cold. The 
messages you receive at this time are: 

VM/370 STARTER SYSTEM VERSION 2.0 

ENTER PRINTER ADDRESS (CUU):00e 

ENTER DEVICE TYPE ( 1403, 1 443, 32 1 1) : 1 403 

ENTER PUNCH ADDRESS (CUU) : OOd 

ENTER DEVICE TYPE (2540P, 3525) : 2540p 

ENTER READER ADDRESS (CUU) : OOc 

ENTER DEVICE TYPE (250 1 , 2540R, 350 5) : 2540r 

ENTER ADDRESS WHERE PID TAPE IS MOUNTED (CUU):280 

ENTER DEVICE TYPE (240 1 , 24 15, 2420, 3420) : 240 1 

ENTER ADDRESS WHERE SCRATCH TAPE IS MOUNTED (CUU) :281 

ENTER DEVICE TYPE (240 1 , 24 15, 2420, 3420) : 240 1 

ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (CUU): 341 

ENTER DEVICE TYPE (23 19, 23 14, 3340, 3330, 2305) : 3340 

♦♦♦SYSTEM DEFINITION COMPLETED^^^ 

OOE PRINTER 
OOD PUNCH 
OOC READER 

280 PID TAPE 

281 SCRATCH TAPE 

341 NEW SYSTEM RESIDENCE 

ARE THE ABOVE ENTRIES CORRECT (YES, NO) :yes 

VM/370 VERSION w LEVEL PLC 0000; mm/dd/yy hh:mm:ss 

NOW 08:54:23 EDT FRIDAY mm/dd/yy 

CHANGE TOD CLOCK (YES | NO): yes 

SET DATE MM/DD/YY :mm/dd/yy 

SET TIME HH:MM:SS :09:04:36 

PRESS "TCD ENABLE SET" KEY AT DESIGNATED INSTANT 

NOW 09:04:36 EDT FRIDAY mm/dd/yy 

CHANGE TCD CLOCK (yES|NO):no 

09:04:38 START ((COLD|WARM) (DRAIN) ) | (SHUTDOWN) :cold 
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09:04:40 

09:04:42 LOGOH AT 09:04:37 BDT FRIDAY mm/dd/yy 

LINE OIF LOGON AS CPGEN USERS= 001 

09:04:42 

DMKCPI952I nnnnK SYSTEM STORAGE 

If you have not defined your system residence volume with a label of 
VMREL2, three messages are issued indicating that the volume labeled 
VI1REI2 is not mounted. If you have labeled it as VHREL2, one or more 
messages are issued indicating VMREL2 conflict. You can ignore the 
following messages. 

09:04:43 FILES: NO RDR, NO PRT, NO PON 
09:04:44 

DMKIOG556I FORMATTING I/O ERROR RECORDING MASK 

09:04:46 

DMKIOG557I FORMATTING MCH ERROR RECORDING AREA 

The TOD clock referred to is the System/370 Time of Day clock. Enter 
the actual date and time in response to the "SET DATE" and "SET TIME" 
messages, and press the TOD Enable Set switch on the system control 
panel when the exact time specified agrees with the installation wall 
clock. 

If, for some reason, you must reload the starter system, the 
following message is displayed: 

VM/370 STARTER SYSTEM VERSION 2.0 

DO YOU WISH TO RE-DEFINE YOUR SYSTEM (YES|NO): 

Respond by entering "no", unless the failure was the result of 
incorrectly specifying the device addresses, or unless the tapes and/or 
disks have been moved. If you reply "yes", you repeat Step 7. 



STEP 8. SET THE TERMINAL MODE AND SPOOL THE CONSOLE 

If the system console you are using is a display device, you should at 
this point, spool your console output so that you have a record of what 
you do. To spool the console input and output, issue the command: 

spool console start 

to save a copy of the system generation. 

Because the default terminal environment for the primary system 
operator is CP, you should also issue the command: 

terminal mode vm 

The virtual machine terminal mode lets you remain in the CMS environment 
when you enter data on the display device. 
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I STEP i« DEFINE OR ATTACH THE SYSTEM BESIDENCE DEVICE 

The CPGEN virtual machine assumes that the system residence volume is 
labeled VMREL2 and is at virtual address 350 if the device type is 3340, 
at virtual address 351 if the device type is 3330, or at virtual address 
352 if the device type is 2314. If you labeled your system residence 
volume VMREL2 in Step 2, your system residence device is already 
available; now you, as the operator of CPGEN, must define it. Use 
Procedure 1 to define your system residence device. 

If you did not label your system residence device VMREL2, you must 
attach it to your virtual machine, CPGEN, now. Use Procedure 2 to 
attach your system residence device. 

For example, if you used the values shown in Step 7, you designated 

the 341 drive, labeled VMRBL2, as your system residence drive for the 

generation procedure. Now you must define your virtual device 350 so 
that it corresponds to a real disk 341. 

Use one of the following procedures to define or attach your system 
residence volume. 

• Procedure 1 

If you labeled your system residence volume VMREL2, but did not 
define its address as 350, you must do so now. Press the Request key 
and enter the command: 

define 350 as 341 

You, as the operator of the CPGEN virtual machine, gain ownership of 
that entire volume as virtual address 350. The CP DEFINE command 
maps this virtual address to the real address of your residence 
system volume as defined in your DMKSYS module. 

Remember that you restored your starter system to a 3340 device. If 
you are now creating a 3330 system residence, with label VMREL2, 
issue the command: 

define 351 as 341 

or, if you are creating a 2314 system residence, with label VMREL2, 
issue the command: 

define 352 as 341 

• Procedure 2 

If you did not label your system residence volume as VMREL2, you must 
attach your system residence volume to your virtual machine now. 
Press the Request key and enter the command: 

attach 341 to cpgen as 341 

Note: The first device address you specify is for the real device; 
the second device address is for the virtual device. The real 341 is 
the system residence volume you formatted in Step 2. The virtual 341 
is the system residence device defined in DMKSYS (with the SYSRES 
macro) and also entered in response to the message: 

ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (CUU) : 
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STEP JO. MAKE OTHER DEVICES AVAILABLE 

You must attach your tape drives and designate the printer to receive 
abnormal termination dumps if they occur. Press the Request key to 
enter each of the following commands: 

attach 280 to cpgen as 181 
attach 281 to cpgen as 182 
set dump OOe 



In the first command, the real tape drive (280) attached must be the 
same real address you entered in Step 7 in response to the message: 

ENTER ADDRESS WHERE PID TAPE IS HOUMTED (CUU) : 

This real device must be attached to CPGEN as 181, because the VMFBLD 
EXEC procedure (which is used later) expects it to be 181. 

In the second command, the real tape drive (281) attached must be the 
same real address you entered in Step 7 in response to the message: 

ENTER ADDRESS WHERE SCRATCH TAPE IS MODNTED (COO) : 

This real device must be attached to CPGEN as 182, because the GENERATE 
EXEC procedure (which is used later) expects it to be 182. 

If only one tape drive is available, enter 

attach 280 to cpgen as 181 

You can define your virtual 181 as 182 later in the system generation 
procedure. 

The address of the real printer, defined in Step 7, is OOE. Any 
system dumps that occur are directed to that address. 

If you wish, you can issue the CP command: 

query virtual all 

before and after performing Step 10, to see how your virtual machine's 
configuration changes. 



STEP 11. LOAD CMS 

Next, you must load CMS from virtual address 190 by issuing the CP 
command: 

ipl 190 

After CMS is loaded, a message is displayed on the system console 
indicating that CMS has successfully loaded: 

CMS VERSION 2.0 - mm/dd/yy hh.mm 

Press the Return key and the CPGEN 191 minidisk is accessed as your 
A-disk. 
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STEP J2. LOAD THE PLC (PROGRAM LEVEL CHANGE) TAPE 

Deaount the PID (Prograi Information Department) starter system tape, 
and moant and ready the PLC tape at 280. 

The PLC tape is prepared by the VM/370 Program Level Change (PLC) 
service. This is a system update service that can include new functions 
as well as cumulative system changes. The latest PLC tape contains all 
new updates, as well as all previous updates since the last VM/370 
release base. IBM Pield Engineering is responsible for initially 
ordering the PLC service. Thereafter, PID automatically ships the PLC 
tapes to the FE location, and FE is responsible for applying the updates 
to VM/370 systems. 

The PLC tape supplied with the starter system should be installed as 
part of the system generation procedure. Issue the CMS command: 

tape load 

The system issues the following messages: 

LOADING 

VMFBLD EXEC A1 
END-OP-FILE OH END-OF-TAPE 

R; 

The VMFBLD EXEC procedure is a service program that adds or replaces 
CP, CMS, or RSCS object modules. It loads the updates from the PLC tape 
for you. Issue the command: 

access 191 c 

because VMFBLD accesses other disks as its A-disk during processing. 
Next, issue the command: 

vmfbld cp 

to execute VMFBLD. 

The VMFBLD EXEC prompts you with the message: 

ENTER CP STAGING AREA DISK ADDRESS: 
194 

You respond with 194. The 194 minidisk belongs to the CPGEN virtual 
machine and is the area on the restored starter system volume that 
contains all the object modules necessary to generate a CP nucleus. The 
contents of the minidisk are updated with the latest versions of all 
object modules, as well as the latest version of the DHKMAC macro 
library. The following message is displayed: 

ARE YOO A NEW USER? — RESPOND (YES|NO) 

You must respond "yes" to this guestion. The following messages are 
then displayed: 

•190« REPLACES •A(194) • 

190 ALSO = S-DISK 

hh:mm:ss RERIND COMPLETE 

CMS VERSION v.O - mm/dd/yy hh.mm 
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The VMFBLD EXEC procedure links to the CMS system disk and accesses it 

ac: -h ho S — /licilr- Moy+ _ UMPRTH T-oarlc: -l-hci nrsfla-fo.'l <^oriiif^o nmnramc: -FT-rsm + Vso 

PLC tape and writes them to the CMS S-disk. Then VMFBLD loads the new 
CMS system onto the system disk. 

After CMS is loaded, a message is displayed to indicate that the CMS 
system was successfully loaded: 

CHS VERSION v.O - Bl/dd/yy hh.mo 

You must enter a null line to continue. 

STEP 13. PUNCH THE SERVICE PROGRAMS 

Use the GENERATE EXEC procedure to punch the service programs. Issue 
the command : 

generate srvcpgm 

These service programs are needed for standalone use; you should 
externally identify the decks and keep them intact. 

The programs punched are: 

• DMKFMT (A three-card loader precedes the DMKFMT text deck) 

• DMKDIR (A three-card loader precedes the DMKDIR text deck) 

• DMKDDR (A three-card loader precedes the DMKDDR text deck) 

• IBCDASDI (The IBCDASDI text deck is loadable) 

The GENERATE EXEC issues the following message: 

THE FOLLOHING STANDALONE SERVICE PROGRAMS ARE BEING PUNCHED 
♦* FORMAT - DIRECT - DUMP/RESTORE - IBCDASDI ** 

PUNCHING • IPL FMT ' ♦****♦ 

PUNCHING • IPL DIR • *♦*♦♦♦ 

PUNCHING • IPL DDR » ****** 

PUNCHING • IPL IBCDASDI • ****** 

Each program deck is preceded by a CP userid card and several 
separator cards, all of which may be discarded. The format of these 
cards is described in the YM^370: Opgrator |s Guide. 

For more information about the GENERATE EXEC procedure, see "Part 6: 
Updating VM/370." 



STEP J4. PRINT AND PUNCH IM STARTER SYSTEM SUPPLIED DIRECTORY, DMKSNT, 
5MSYS, AND DMKFCB 

After the service programs are punched, the GENERATE EXEC asks you 
whether you want a copy of the Release 2 directory printed. You should 
respond "yes." 
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PRINT COPY OF RELEASE2 DIRECT? ~ RESPOND (YES|NO): yes 

This prints a copy of the Release 2 directory, as well as copies of the 
DMKSYS ASSEMBLE (the CP system control file) , DMKFCB ASSEMBLE (the forms 
control buffer file) , and DMKSNT ASSEMBLE (the system name table) 
provided with the starter system. 

The GENERATE EXEC procedure issues the following message: 

A SAMPLE DIRECTORY IS BEING PRINTED TO AID YOU. 
IT SHOWS WHERE THE VIRTUAL DISKS ARE LOCATED ON 'CPV2L0' 
YOU MAY USE THESE MINIDISKS FOR OTHER VIRTUAL MACHINES, 
IN PARTICULAR THE CMS SYSTEM DISK ( MAINT 190 ) AND 
THE CP STAGING AREA DISK ( MAINT 194 ) 
INCLUDED IN THIS DIRECTORY IS THE USERID: MAINT 
WHICH WILL BE USED FOR FUTURE SUPPORT OF THE SYSTEM. 
THIS USERID SHOULD BE INCLUDED IN THE DIRECTORY 
YOU BUILD FOR YOUR FLOOR USE. 

♦* CAUTION ♦♦ IF YOU DESTROY USER MAINT'S AREAS, IT WILL BE 
NECESSARY TO RE-BUILD THE ENTIRE SYSTEM. 

A SAMPLE OF DMKSYS, DMKFCB, AND DMKSNT ASSEMBLE ARE ALSO BEING 

PRINTED TO AID YOU. THIS SAMPLE DMKSNT IS BASED ON THE 

INFORMATION INCLUDED IN THE SAMPLE DMKSYS AS WELL AS THE 

EXAMPLE ALLOCATIONS FOR VMHEL2 PROVIDED IN THE SYSGEN GUIDE. 

A COPY OF THIS DMKSNT MODULE HAS BEEN INCLUDED IN THE CP NUCLEUS, 

SUCH THAT IF ONE USES THE INCLUDED DMKSYS AND THE 

SAMPLE ALLOCATION PROVIDED IN THE SYSTEM GENERATION GUIDE, 

HE WILL BE ABLE TO SAVE HIS CMS SYSTEM UPON COMPLETION 

OF THE SYSTEM GENERATION PROCEDURE. A COPY OF DMKFCB HAS BEEN 

INCLUDED IN THE NUCLEUS AND NEED NOT BE RE-ASSEMBLED FOR 

SYSTEM GENERATION. IT HAS BEEN INCLUDED FOR THE USER WHO WOULD LIKE 

TO MODIFY OR ADD TO THE EXISTING BUFFER LOAD. 

NOTE: IF THE USER WISHES TO MODIFY THE SAMPLE DMKSNT AND/OR DMKFCB 
HE MAY INCLUDE THE UPDATED SOURCE WITH THE SOURCE INCLUDED UNDER 
THE OPTION 'GENERATE VM370' , OF THE SYSTEM GENERATION PROCEDURE. 
IF PRESENT, IT WILL AUTOMATICALLY BE ASSEMBLED AND INCLUDED IN THE 
NEW CP NUCLEUS. 

Again, the GENERATE EXEC procedure prompts you: 

DO YOU WISH TO HAVE A COPY OF DMKSNT, DMKSYS, DMKFCB, AND 
RELEASE2 DIRECT PUNCHED TO CARDS? — RESPOND (YES|NO): 

You should enter "yes" to have these decks punched. "Part 2: Defining 
Your VM/370 System" contains a listing of the Release 2 VM/370 directory 
and the DMKSNT, DMKSYS, and DMKFCB modules supplied with the starter 
system. The following messages are issued to indicate the files that 
are being punched: 

PUNCHING ' DMKSNT ASSEMBLE • ****** 

PUNCHING • DMKSYS ASSEMBLE • ****** 

PUNCHING • DMKFCB ASSEMBLE ' ****** 

PUNCHING • RELEASE2 DIRECT ' ****** 

R; 
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STEP J5. BUILD THE VM/iVO DIRECTORY AND ASSEMBLE THE FILES DEFINING THE 
~ mi IZO IHD SYSTEM DEVICES 

Next, you should place the files describing your installation's version 
of the VM/370 directory, real I/O configuration, and system devices in 
the reader and invoke the GENERATE EXEC procedure to build the directory 
and assemble the files describing the configuration. Place the 
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I ID CPGEH 

I :READ filename DIRECT 

I (Directory program control statements) 

I :READ DHKRIO ASSEMBLE 

I (Real I/O configuration macros) 

I :READ DBKSYS ASSEMBLE 

I (CP system control file macros) 

I The Directory program control statements, real I/O configuration macros 

I and system control macros are those you created according to the 

I instructions in "Part 2: Defining Your VM/370 System." You can code 

I your own system control macros or add to the file supplied with the 

I starter system. 

I Also, if you want, you can change the printer buffer load (DMKFCB) or 

i the named system (DMKSNT) modules to conform to local reguirements. If 

j you want to change the printer buffer load or the system name table, you 

I should add your changes to the files already punched (in Step 14) and 

I place the following files in the card reader behind the system control 

I file macros: 

I :READ DMKFCB ASSEMBLE 

I (forms control macros) 

I :READ DMKSNT ASSEMBLE 

I (system name table macros) 

I Instructions for creating new forms control macros are in the VM/370 ; 

I System Programmer^ Guide. The system name table macros are described 

I in "Part 2: Defining Your VM/370 System" of this manual. 



I FORMAT OF THE READ CONTROL STATEMENT 



The READ 
format: 



control statements must be punched according to the following 



Column 


Number of 
Characters 


Conten 


ts 


Meaning 






1 




1 




colon' 


. 1 


Identifies card 


as a 


control card 


2-5 




4 




READ 




Identifies card 


as a 


READ control card 


6-7 




2 




blank 










8-15 




8 




fname 




Filename of the 


file 


punched 


16 




1 




blank 










17-24 




8 




ftype 




Filetype of the 


file 


punched 


25-80 




56 




blank 











I SPECIAL PROCEDURE IF YOU ARE USING ONLY ONE TAPE DRIVE 



I If you are using only one tape drive, at this time you must issue the 
I command : 



define 181 as 182 
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Now mount the scratch tape in place of the PLC tape and ready the 
device. 



I INVOKE THE GENERATE EXEC PROCEDURE 

I When all the files are placed in the reader, invoke the GENERATE EXEC 
I procedure by issuing the following command: 

I generate vm370 

I This procedure invokes the Directory service program to build the 
I disk-resident VM/370 directory, then assembles the DMKRIO and DMKSYS 
I files that you placed in the real card reader. After the Directory 
I service program execution completes, the DMKRIO and DMKSYS files are 
I assembled in preparation for building the new CP system nucleus. 
I GENERATE then checks for DMKFCB and DMKSNT source files. When new 
I versions of the DMKFCB and DMKSNT modules are provided, GENERATE 
I assembles the new modules and replaces the corresponding modules 
I supplied with the starter system with the new modules. If any errors 
I occur while the VM/370 directory is being built, the Directory program 
I issues error messages and the GENERATE EXEC procedure issues the 
I following message: 

I CORRECT THE DIRECTORY CARDS AND RELOAD THE CARD READER 
I RESPOND WITH: GENERATE DIRECT 

I Correct the errors in the Directory program control statements, and 
I reload the card reader with only the ID card, the :READ statement, and 
I the Directory program control statements. Then respond with: 

I generate direct 

I If errors are detected while the DMKRIO, DMKSYS, DMKFCB, or DMKSNT 
I files are assembling, GENERATE issues a similar message: 

I CORRECT THE filename ASSEMBLE FILE AND RELOAD THE CARD READER 
I RESPOND WITH: GENERATE filename 

I You must correct the errors in the indicated file, and reload the card 
I reader with only the ID card, the :READ statement, and the appropriate 
I file. Then, issue the GENERATE command with the appropriate option. 
I For example: 

I generate dmksys 



I STEP 16. SPECIAL CONSIDERATIONS FOR VIRTDALfREAL MACHINES 

I Once the directory is built and the files are assembled, the GENERATE 

I EXEC procedure asks if you want the virtual=real option included in your 

I CP nucleus: 

I VIRTOAL=REAL OPTION REQUIRED (YES, NO) : 

I If you respond "yes" to this guestion, you are prompted to enter the 

I amount of storage you wish to reserve in the CP nucleus for a 

I virtual=real machine. ("Peirt 1. Planning for System Generation" 

I contains formulas to help you determine how much storage you need to 

I reserve.) This size must be a multiple of 4K and must be entered in the 
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format nnnnK. The minimum size you can specify is 32K and the maximum is 
£iM. For exas'^iej 

STORAGE SIZE OF VIRT=REAL (MINIHOM IS 32K) : 

lOOk 

0100K STORAGE SIZE FOR VIRTOAL=REAL 

IS THE ABOVE EHTRY CORRECT (YES, HO) : 

yes 

You must have enough virtual storage available to generate the CP 
nucleus with a virtual=real area. The "Specifying a Virtual=Real 
Machine" section of Part 1 tells you how to determine the amount of 
virtual storage you require. If you do not have enough virtual storage 
available, redefine storage for your virtual machine. 



STEP 17. LOAD THE CP NOCLEOS 

Once you respond to the virtual=real generation questions, the GEHERATE 
EXEC procedure writes the CP nucleus on tape. To do this, GEHERATE 
first issues the VHFLOAD command to punch the loader and CP object 
modules to a virtual punch spool file. Then it transfers this file to 
the virtual card reader file and writes the file on tape. GEHERATE 
issues the following messages during the processing: 

hh:mm:ss HO FILES PURGED 
SYSTEM LOAD DECK COMPLETE 

hh:mm:ss PUH FILE nnnn TO CPGEH COPY 01 HOHOLD 
IPLABLE HUCLEOS HOW OH TAPE ♦*** 

hh:mm:ss PRT cuu OUTPUT OF CPGEH FILE-nnnn RECDS=nnnnnn 
COPY = 01 A PRT 

Hote: If any errors are detected while the tape is being written, you 
must recreate the CP nucleus. To do this, issue the command: 

generate cp nucleus 

The i^rocedure restarts at Ste*^ 16 where von are asked if ■'^ou want the 
virtual=real option. 



LOADIHG A CP HUCLEUS HITBOUT A VIRTUAL^REAL AREA 

If you responded "no" when asked if you wanted the virtual=real area, 
the GEHERATE EXEC procedure loads the nucleus for you. You receive the 
following message: 

HHEH 'HUCLEUS LOADED OH XXXXXX' IS TYPED, ISSUE 'CLOSE PRT', 
TO GET THE CPLOAD MAP. RHEH PRIHTIH6 IS COMPLETE, 
SHUTDOHH THE SYSTEM AHD IPL THE HEN SYSRES VOLUME. 

When the nucleus is written on the system residence volume, the message 

HUCLEUS LOADED OH volid 

is issued, where volid is the volume serial number of your system 
residence volume. The volid is the serial number you specified on the 
SYSRES macro when you prepared the CP system control file (DMKSYS) . If 
you followed the example in this manual, the serial number of your 
system residence volume is VHREL2. 
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To print the load map you must close the printer; issue the command: 

close prt 

When printing is complete, shutdown the system in preparation for 
loading your newly generated CP nucleus: 

shutdown 

LOADING A CP NUCLEUS THAT HAS A VIRTUAL=REAL AREA 

If you responded "yes" when asked if you wanted the virtual=real area, 
the GENERATE EXEC procedure issues the following message: 

TO LOAD THE CP NUCLEUS JUST CREATED, SHUTDOWN THE SYSTEM AND 
THEN IPL THE TAPE. THE CPLOAD MAP HILL AUTOMATICALLY BE PRINTED AT THE 
PRINTER WHOSE ADDRESS IS 'OOE*. IF THERE IS NO PRINTER AT THIS ADDRESS 
THE LOAD MAP WILL BE PRINTED AT THE FIRST PRINTER CAUSING AN INTERRUPT 
(IE. NOT-READY TO READY SEQUENCE) . ONCE THE NUCLEUS HAS BEEN LOADED, 
YOU MAY IPL YOUR NEW CP SYSTEM RESIDENCE VOLUME. 

NOTE: THERE MUST BE ENOUGH STORAGE ON THE SYSTEM (VIRTUAL OR REAL) TO 
CONTAIN THE VIRT=REAL AREA AND THE CP NUCLEUS. 

You must be sure that there is enough storage to load the CP nucleus 
with a virtual=real area before you load it. The "Specifying a 
Virtual=Real Machine" section of Part 1 tells you how to determine the 
amount of real or virtual storage you need. You can load a CP nucleus 
that has a virtual=real area in either a real or virtual machine. 

You IPL the tape containing the CP nucleus next. The CP nucleus is 
on the tape at virtual address 182 for the CPGEN virtual machine. 



STEP J8. IPL THE M^hl GENERATED VM/320 

IPL the newly created system residence volume by setting the load unit 
address dials to the address of the system residence volume and pressing 
the Load button. The userid OPERATOR (or whatever userid you specified 
as the system operator on the SYSOPER macro) is logged on when you IPL. 
The following messages are issued. Respond as shown. 

VM/370 VERSION vv LEVEL 00 PLC nnnn; mm/dd/yy hh:mm:ss 

NOW hh:mm:ss EDT day mm/dd/yy 

CHANGE TOD CLOCK (YES|NO):no 

hh:mm:ss START ((COLD|WARM) (DRAIN) ) | (SHUTDOWN) : cold 

hh:mm:ss LOGON AT hh:mm:ss EDT day mm/dd/yy 

hh:mm:ss LINE OIF LOGON AS OPERATOR USERS = 001 

hh:mm:ss 

DMKCPI952I nnnnK SYSTEM STORAGE 

hh:mm:ss FILES: NO RDR, NO PRT, NO PUN 
hh:mm:ss 

DMKI0G556I FORMATTING I/O ERROR RECORDING AREA 
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hh:miD:ss 

DMKI0G557I FORMATTING MCH ERROR RECORDING AREA 

At the tine you IPL your newly generated VM/370, your system 
residence volume is formatted according to your specification on the 
SYSRES macro. Also, if you used the VM/370 directory supplied with the 
33U0 starter system, your starter system volume (CPV2L0) is set up as 
shown in Figure 22. Be careful not to modify the 190 and 194 minidisks 
for the MAINT user. These minidisks and the information they contain 
are required for applying PLC (Program Level Change) updates to VM/370. 



1 Real 1 Number of | 

! Cylinder ! Cylinders j Contents 


i 1 1 1 Unused 


1 1-2 1 2 1 191 minidisk for the IVPMl user 


1 3-4 1 2 1 191 minidisk for the IVPM2 user 


1 5-6 1 2 1 191 minidisk for the REM2780 user 
1 7-20 1 14 1 191 minidisk for the OPERATOR user 


1 21-26 1 6 1 191 minidisk for the CE user 


1 27-40 1 14 1 191 minidisk for the MAINT user 


1 41-45 1 5 1 191 minidisk for the ECMODE user 


1 46-47 1 2 1 199 minidisk for the MAINT user 


1 48-250 1 203 | 190 minidisk for the MAINT user 

1 1 1 Note: The last two cylinders of this minidisk 
1 1 1 contain the CMS nucleus. 


1 251-348 1 98 | 194 minidisk for the MAINT user 


IE2tf' Cylinders 349-697 are not used for a 3340 Model 70 system 
1 residence volume. 



Figure 22. Allocation of the Starter System Volume (CPV2L0) When the 
3340 Starter System Directory Is Used 



I STEP 19. BACK UP THE NEWLY GENII AT ED VM/370 



At this time, you should be sure to back up your new system residence 
volume. If your real machine has at least 448K bytes of real storage, 
the tape created in Step 17 is sufficient backup. However, that tape is 
not sufficent backup for real systems with less than 448K of real 
storage because that tape cannot be loaded on such systems. 

VM/370 systems that run on a real machine with less than 448K bytes 
of real storage should use the DASD Dump Restore (DDR) service program 
to create a backup tape similar to the one created in Step 17. The DASD 
dump restore program is described in Appendix F. If your system 
residence volume is at address 341 and you labeled it VMREL2, you could 
use the following DDR control statements to back it up: 
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input 3ai 3340 vmrel2 
output 180 3U20 
dump nucleus 

The tape produced contains the CP nucleus; it does not contain the 
VM/370 directory. However, you already created a standalone version of 
the Directory program in Step 13 and have the Directory program control 
statements, which you used in step 15, to recreate the VM/370 
directory. 

If you do not wish to use the DDR program to back up your system, you 
can load the tape produced in Step 17 in a virtual machine. If you load 
the tape in a virtual machine that virtual machine must have (1) 512k of 
storage and (2) write-access to the system residence volume, at the 
address defined for system residence in the SYSHES macro of the CP 
System Control (DMKSYS) file. 

When you use the DDR program to back up your system you do not get a 
load map when you restore the tape. You do get a load map if you load 
the tape produced in Step 17. 



I STEP 20. MOVE THE CMS SYSTEM DISK, IF YOU WISH 

The CP nucleus just created is tailored to your installation's exact I/O 
configuration with all the appropriate options selected. The CMS 
nucleus requires no special tailoring for installation. The CMS system 
residence disk was created when the VM/370 starter system was loaded; it 
contains a copy of the CMS nucleus and disk-resident command modules. 
At this point, the CMS system resides on the virtual 190 disk for the 
user, MAINT. The operator's VM/370 directory has an entry that links to 
MAIHT's 190 disk, therefore you can invoke CMS ty issuing the command: 

ipl 190 

and thus have access to most of the CMS functions. Although most of the 
CMS functions are available, CMS has not yet been updated with the 
latest PLC changes. The Assembler that is available now is the one 
supplied with the starter system. 

If you wish, you can move the CMS system disk to a disk other than 
the one designated by the starter system. To move the CMS system disk 
to another minidisk, use the COPY function of the DDR service program. 
The new minidisk should be the same size as the CMS system disk, but it 
does not need to be formatted. Also, if you move the CMS system, you 
must make the appropriate changes to the userid MAINT in your VM/370 
directory (that is, change the volume label on the MDISK entry for 
190) . 

If you add IBM Program Products or your own disk-resident modules to 
the CMS system disk, you may have to create a new system disk to contain 
the additional modules. The "Creating a CMS System Disk" section of 
"Part 6. Updating VM/370'' describes this procedure. 



I STEP 2 J.. FORMAT THE 0PERAT0R2.S VIRTUAL J9J DISK 

I Before any new minidisk area can be used for CMS files, it must be 
I initialized with the CMS FORMAT command, which formats the area into 
I 800-byte blocks. Take care not to format areas which contain data 
I restored from the starter system (such as the 190 and 194 minidisks 
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belonging to the user MAINT.) The CMS FORMAT command is described in 
the VM/370: Command Lan^uaae Guide for General Users. 

Hote: After you complete this step, a portion of the starter system is 
overlaid by the operator's virtual 191 minidisk. If for any reason you 
wish to IPL the starter system again, you must restart at step 1. 

At this time you are logged on as the operator. Use the following 
procedure to format your virtual disk 191. First, load CMS (IPL 190). 
CMS responds with: 

CMS VERSION 2.0 - mm/dd/yy hh:mm 

Next, enter the following command: 

access (nodisk 

The NODISK option prevents CMS from automatically accessing your virtual 
disk 191. (Accessing 191 at this time would causes an error message to 
be issued because 191 is not yet initialized, and therefore cannot be 
used.) After the Ready message is displayed, issue the command: 

format 191 a 

The CMS FORMAT command prompts you with the following message: 

FORMAT HILL ERASE ALL FILES ON DISK 'A (191)'. DO YOU WISH TO 
CONTINUE? (YESINO): 

If you respond yes, CMS prompts you with: 

ENTER DISK LABEL: 
opr191 

Enter the one- to six-character alphameric label of the virtual disk. 
You can use whatever label you wish for this virtual disk. In this 
example, the label is 0PR191. CMS then issues: 

FORMATTING DISK 'A', 

•14' CYLINDERS FORMATTED ON "A (191)'. 

and a Ready message. 



STEP 22. FORMAT THE MAINT USERIS 191 DISK 

Next, you should initialize the 191 disk belonging to MAINT, in the same 
way you initialized the operator's 191. Log yourself off the system and 
log on again as userid MAINT, using the password CPCMS. Now IPL 190. 
Hhen the CMS Ready message is displayed, issue 

access (nodisk 

and continue to format MAINT 's 191, using the same procedure you used to 
format 0PR191. 
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I STEP 23. UPDATE CMS 

I Now that the MAINT 191 ninidisk is formatted, you (as the MAINT user) 
I can update CMS with the changes supplied on the PLC tape. Mount the PLC 
I tape, if it is not already mounted. Then, you must attach the real tape 
I drive to your CMS virtual machine (MAINT) ; for example: 

I attach 280 to maint as 181 

I and, with the 191 minidisk that belongs to MAINT accessed as your 
I A-disk, rewind and load the tape: 

I tape rew 
I tape load 

I CMS responds with the following message: 

I LOADING 

I VMFBLD EXEC A 

I END-OF-FILE OR END-OF-TAPE 



I BUILDING A NEW CMS 

I Now execute the VMFBLD EXEC procedure by issuing the commands: 

I access 191 c 
I vmfbld cms 

I The VMFBLD EXEC procedure prompts you with: 

I ENTER CMS SYSTEM DISK ADDRESS: 

I You respond with "190". Next, VMFBLD issues the message: 

I 190 ALSO = S-DISK. 

j You are asked if you want the service programs punched : 

I PUNCH STANDALONE SERVICE PROGRAMS — RESPOND (YES|NO): 

I The following messages are displayed; respond as shown: 

I hh:mm:ss NO FILES PURGED 

I hh:mm:ss NO FILES PURGED 

I SYSTEM LOAD DECK COMPLETE 

I hh:mm:ss PUN FILE nnnn TO CPGEN COPY 01 NOHOLD 

I hh:mm:ss REWIND COMPLETE 

I WHEN THE NEW CMS SYSTEM IS BUILT ISSUE THE FOLLOWING 

I COMMAND 

I CLOSE PRT . . . (PRINTS THE LOAD MAP) 

I DMSINI606R SYSTEM DISK ADDRESS = 190 
I DMSINI615R Y-DISK ADDRESS = 1 9e 
I DMSINI607R REWRITE THE NUCLEUS ? yes 
I DMSINI608R IPL DEVICE ADDRESS = 190 
I DMSINI609R NUCLEUS CYL ADDRESS = 201 
I DMSINI610R ALSO IPL CYLINDER ? yes 
I DMSINI611R VERSION IDENTIFICATION = 
I DMSINI612R INSTALLATION HEADING = 
I CMS VERSION 2.0 - mm/dd/yy hh:mm 
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In the example, the 190 you entered is the 190 minidisk that belongs 
to the user MAINT; it is equivalent to the 190 minidisk that belongs to 
CPGEM. If you used the VM/370 directory supplied with the starter 

a-aa-t-am •an\^ a 1 1 .—.i-a + cs.-l OCi'i i^rt 1 -i nA ar c: / it -i i- + « a 1 r- ii 1 ■? rs .-1 ii t- cr f>.=Ori'5\ + .— . + Kri 1 Q .O 

^J^^.^^, jw- ^^^^^^y,^:^ ^v^ y^j ^^*±,^^M.^ yw^^^xty^^ w j ^^ u v^ v. A. w^ w *. w ^ / y. ^ ^ »* %- i^w 

minidisk belonging to the user MAINT. The last two cylinders of this 
minidisk contain the CMS nucleus, therefore you specify cylinder 201 as 
the nucleus cylinder address when responding to message DMSINI609R. 

When the VMFBLD EXEC procedure completes its execution, the CMS 
system residence volume is updated with the most current object modules 
(text decks) and load modules, and the new CMS nucleus is written on the 
CMS system residence volume. 

Also, if there are any updates for the EREP program or the Assembler 
on the PLC tape, the VMFBLD EXEC procedure updates those programs and 

Luxng auxxj-xary uirectcrxes. 



I STEP 24. SAVE CMS 

If you used the sample DMKSNT and DMKSYS supplied with the starter 
system, and used the sample allocations shown in Step 2, you can now 
save your CMS system. 

To save the CMS system, you must load it and then save it as soon 
after loading as possible. Issue the command: 

ipl 190 

When the terminal unlocks, do not press carriage return, but immediately 
issue the command: 

savesys cms 

Then press carriage return. If CMS is successfully saved, the message 

hh:mm:ss SYSTEM SAVED 

CMS VEESIOS 2.0 - mm/dd/yy hh:mm 

is displayed. Your CMS system is now saved; you can issue IPL CMS 
instead of IPL 190, when you wish to run CMS. 

If you named your CMS system something other than CMS, such as CMS1, 
the entry you made in the system name table would be for CMS1, you would 
have to save CMSl (SAVESYS CMS1) and then you could IPL CMS1. For more 
information about how to save CMS, see the VM/370 : System Pro^rammer^^s 
Guide or the "Saved Systems" section of this manual. 

At this point, use the Installation Verification Procedure (IVP) to 
test the new system. Log off as the userid MAINT and log on again as 
the userid OPERATOR, using the password OPERATOR. The IVP description 
follows. 
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Verifying CP and CMS Using the IVP 



The Installation Verification Procedure (IVP) for VM/370 exercises CP 
and CMS to verify that they are working properly. The IVP is contained 
in two files using the EXEC facility of CMS, and uses two virtual 
machines in addition to the system operator's virtual machine. 

The tests exercise the following areas of CP: 

Multiple virtual machine support 

I/O spooling 

Transferring of spooled data to other virtual machines 

Offline I/O operations 

Sending of messages to the system operator 

Paging operations 

Task dispatching and scheduling 

Disk I/O support 

Automatic warm start following abnormal termination of VM/370 

The following facilities of CMS are exercised: 

Normal CMS command processing 

Disk formatting 

Copying of files 

Creation and modification of files via EDIT command 

Assembly of executable programs 

Execution of user programs 

Creation and execution of user-written commands 

Printing and punching of CMS files 

Issuing of commands to CP 

Use of multilevel nested EXEC procedures 

Stacking and unstacking of command and data input from the terminal 

Communication with user from EXEC procedures 

Several other system facilities, incidental to the primary IVP tests, 
are exercised. Certain system facilities such as preferred execution 
I options, virtual=real, OS ISAM, remote 2780, and RSCS (Remote Spooling 
I Communications Subsystem) are not exercised by the IVP. The IVP 
requires operator intervention only when an operational decision is to 
be made, or to initiate the IVP tests themselves. All file creation, 
erasure, management, alid logoff of the virtual machines (with the 
exception of the system operator) at test completion is performed 
without operator or user action. 

The IVP tests use only the system-provided facilities. All unique 
test programs are created, assembled, and subsequently erased by the 
IVP. 

IICIIITIES BEjQOIRED FOR EACH IVP VIRTUAL MACHINE 

All VM/370 configurations are supported. The IVP executes under the 
control of CMS. The other facilities required are: 

• The Assembler 

• One virtual read/write disk accessed as the A-disk (normally at 
virtual address 191) 

• 320K of virtual storage (16M for IVPM1) 
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STARTING THE IVP 

The IVP must be executed to formally complete the initial installation. 
(See "Variations of the IVP" for post-installation testing.) It 
requires two virtual machines (IVPM1, IVPM2) which must be described in 
the VM/370 directory. 



The directory entries for the IVP virtual machines, IVP1 and IVP2, 
are xncluded in the Vi5/370 directory supplied with the starter system; 
these entries should be included in your own directory. 



You, as the system operator, execute the IVP. To initiate the IVP 
tests, enter the command: 

IVP 

and then answer "yes" or "no" to the following question: 

ARE YOD THE SYSTEM OPERATOR? ENTER "YES" OR "NO": 

If you enter the IVP command with no parameters specified and then 
reply that you are not the system operator, the IVP tests default to the 
single virtual machine verification procedure. (See "Variations of the 
IVP.") 

Prompting instructions are displayed whenever you must perform an 
operation or issue a command. 

Log on the virtual machine (IVPMl) , using the password IVPASS, and 
IPL CMS to continue the testing procedure: 

logon ivpml 

ENTER PASSWORD: 

ivpass 

LOGON AT 09:55:00 EST FRIDAY 03/29/74 

define storage 16384k 

STORAGE=1638aK 

ipl 190 

CMS VERSION 2.0 mm/dd/yy hh.mm 

ivp 1 

At this point, the tests begin on virtual machine 1. After the 
disconnect message is displayed, follow the prompting messages that are 
displayed. These messages tell you to log on the IVPM2 virtual machine 
(this may be done on the same terminal) , as shown: 

logon ivpm2 

ENTER PASSWORD: 

ivpass 

LOGON AT 09:58:30 EST FRIDAY 03/29/74 

ipl 190 

CMS VERSION 2.0 mm/dd/yy hh.mm 

ivp 2 

At this point, the remainder of the tests begin on virtual machine 
2. The final phase of the IVP tests consists of displaying, printing, 
and punching a file which contains the messages generated by IVPMl 
following the DISCONNECT. 
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Upon completion of the tests, the IVP EXEC procedure logs off. The 
system abnormal termination test, which consists of forcing an ABEND 
dump of VM/370 and the subseguent warm start, is an option that you must 
specify in response to messages that are displayed. For the purpose of 
installation verification, you should select this option. You are 
instructed to delay starting the spooling devices (reader, printer, and 
punch) until after the warm start procedure. 



lASIlTIONS OF THE IVP 

If you wish, you may run the IVP procedure after initial installation, 
using any one of the following methods: 

• Executing the IVP without testing the system abnormal termination 

• Executing the IVP using virtual machines other than IVPM1 and IVPM2 

• Executing the IVP in a single virtual machine 

When you execute the IVP in a single virutal machine, inter-machine 
functions, such as transferring data between virtual machines, are not 
exercised. 

To execute the IVP without testing system abnormal termination: 

• Retain the created virtual machines in your VM/370 directory. 

• Execute the IVP as described previously under "Starting the IVP," but 
do not select the "system abnormal termination" option. 

To execute the IVP with virtual machines other than IVP1 and IVP2: 

• Enter, in place of the command IVP 1: 

IVP 1 useridi 

• Enter, in place of the command IVP 2: 

IVP 2 userid2 

where useridi and userid2 identify the two virtual machines in which the 
EXEC procedures IVP 1 and IVP 2 (respectively) are to be executed. 

To execute the IVP in a single virtual machine, enter the command 
(from any logged-on virtual machine) : 

IVP * 

This causes the IVP tests to be run in that single virtual machine. 
Inter-machine transfer of data is simulated by transferring virtual 
punched output to the same virtual machine's virtual card reader. 
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INTEBPRETIMG THE TEST EESOLTS 

Messages at the end of the IVP test indicate successful completion. If 
any errors are detected by the IVP, notify the IBM FE Program Systems 
Representative, since an error usually indicates a serious malfunction 
of the generated system. The IVP procedure identifies each command being 
tested just before the command is executed. 

Error messages are displayed in a four-line format, for example: 

*** IVP FAILURE HAS OCCURRED *** 
*** COMMAND: STATE IVPTST * 
*** EXPECTED RETURN CODE 28 
*** RECEIVED RETURN CODE 

These messages indicate that the CMS STATE command had a return code of 
0, instead of the expected 28. 

All information messages that originate within the IVP are preceded 
by three asterisks (***) . 

If any command fails, the IVP procedure terminates. Fellow the 
instructions (if any are given) to log off the virtual machine. 
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I Generating and Installing RSCS 



I GENERAL INFORMATION 

The data and control files required to generate and install RSCS are 
contained on the Program Level Change (PLC) tape of the VM/370 system. 
You can use the PLC installation EXEC procedure (VMFELD) to load the 
RSCS data onto the CP staging area. Four modules must be moved from the 
CP staging area disk to the RSCS system disk: DMTAXS, DMTLAX, DMTNPT and 
DMTSML. 

RSCS data, on the PLC tape, consists of the following: 

Pile Contents 

DMTxxx TEXT The pre-assembled nucleus modules and supervisor 
routines required to generate RSCS are: DMTAKE, DMTASK, 
DMTASY, DMTCMX, DMTCOM, DMTCRE, DMTDSP, DMTEXT, DMTGIV, 
DMTINI, DMTIOM, DMTMAP, DMTMGX, DMTMSG, DMTPST, DMTQRQ, 
DMTREX, DMTSIG, DMTSTO, DMTSVC, DMTVEC, and DMTWAT. 

DMTAXS TEXT The spool file access method supervisor task. 

DMTLAX TEXT The communication line allocation supervisor task. 

DMTNPT TEXT The Nonprogrammable Terminal (NPT) line driver module. 

DMTSML TEXT The Spool MULTI-LEAVING (SML) line driver module. 

DMTLOAD EXEC The loadlist EXEC file. This file is required to 
generate an RSCS nucleus on the RSCS system task. 

DMTSYS ASSEMBLE The RSCS configuration table module. This file must be 
assembled with the COPY files you create to define your 
RSCS configuration (the AXSLINKS, LAXLINES, and 
TAGQUEUE COPY files) . 

DMTMAC MACLIB The file containing all the macros needed to assemble 
the RSCS source files. 

DMTR20 CNTRL The control file that is needed to assemble the 
configuration table via the VMFASM EXEC procedure. 

DMTxxx ASSEMBLE All the source files for RSCS. There is an ASSEMBLE 
file for each TEXT file previously listed. 

DMTMAC EXEC An EXEC file used to generate the DMTMAC MACLIB. 

Also, the PLC tape contains all the macro and copy files included in the 
DMTMAC macro library. 



PJII5ING YOUR RSCS VIRTUAL MACHINE 

You need the RSCS virtual machine defined when you generate RSCS. This 
virtual machine must have 512K of virtual storage, a console, and a 
5-cylinder RSCS system disk with a write password. 
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I If you did not include an entry in your VM/370 directory for the RSCS 

I virtual machine, you must add one now. See "Part 2: Defining Your 

I VM/370 System" for a description of the Directory program, including the 

I control statements necessary to define a virtual machine. Add the 

I r\ f^ia 1 ^T .^ j^r\A ^% A ^-i r\ r\ -^ r r\ ^ c*+'^4=rf-ki»rf^T-. ♦'^^ ♦-rf-v 4-1*/% /-k^rne^+-iTij-» A A t^ /r^ j^-^ j^-r xr -^ A ^ ^\ '^ -n A 

I assemble and load the new VM/370 directory. Use the GENERATE EXEC 

I procedure to assemble and load your updated VM/370. GENERATE is 

I described in "Part 6: Updating VM/370." 

I A suggested VM/370 directory entry for an RSCS virtual machine is: 

I USER RSCS password 512K 

I ACCOUNT NUMBER BIN17 

I CONSOLE 009 3215 

I SPOOL 001 2540 READER A 

I SPOOL C 2540 READER A 

I SPOOL E 1403 A 

I LINK CMSSYS 190 190 R 

I MDISK 191 3330 81 5 UDISK1 W password 

I DEDICATE OBI 078 

I DEDICATE 0B2 079 

I DEDICATE 0B3 07A 

I If you plan to run multiple concurrent RSCS virtual machines, you 

I must define multiple RSCS virtual machines in your VM/370 directory. 

I Also each RSCS virtual machine must have a unigue system disk with a 

I unique local location identification generated. 



I DEFINING YOUR RSCS SYSTEM 

I You must create three files to define your RSCS system: 

I liie What It Defines 

I AXSLINK COPY All the possible paths for data transmission between 

I your RSCS virtual machine and all the single uniquely 

I identified remote stations. 

I LAXLINES COPY The virtual device addresses of all the switchable 

I telecommunications line ports dedicated to the RSCS 

I virtual machine. 

I TAGQUEUE COPY Total number of virtual storage tag slots. A tag slot 

I contains spool file information needed by RSCS when it 

I processes files. 

I These three files are used to generate the DMTLOC macro library during 

I the RSCS installation procedure. The DMTLOC macro library is used when 

I the RSCS configuration table module (DMTSYS) is assembled. 



I CREATING THE AXSLINKS COPY FILE 

I The AXSLINKS COPY file defines the set of links to be loaded in the RSCS 

I configuration table module. A link is a potential path for data 

I transmission between an RSCS virtual machine and a single uniquely 

I identified remote station. 

I The AXSLINKS COPY file is a list of 1 to 64 GENLINK macro 
I statements. The GENLINK macro defines the attributes of a link. The 
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first GENLINK macro in the AXSLINKS file must contain the ID of the 
local RSCS station. You must also code the TYPE=driverid operand with a 
valid filename on this first GENLINK macro. You should code additional 
GENLINK macros, with no operands, for links you may want to define 
temporarily during an operating session. 

The format of the GENLINK macro is: 



r 1 

I ID=linkid,TYPE=driverid[ ,CLASS=c] | 

I [ ,KEEP=holdslot] I 

I [ ,LINE=vaddr] | 

I [ ,TASK=taskname] | 

L J 



wh ere : 

ID=linkid is a one— to eight— character alphameric location ID of the 
remote location to be served by the link. If this operand is 
not specified, the ID defaults to "undefined." 

TYPE=driverid 

is a CMS filename of a file which is the TEXT file for the 
line driver program to be used to process files for the link. 
The appropriate line driver program to be specified depends on 
the type of remote telecommunications facilities to be used. 

The TYPE operand must be specified if ID=linkid is coded. If 
the TYPE operand is omitted, the TYPE defaults to 
"undefined". 

CLASS=c is the spooling class (es) of the files which can be processed 
by the active link. You can specify up to four spooling 
classes (single alphameric characters from A to Z and to 9) 
with no intervening blanks, or *, which means all spool file 
classes may be processed. If the CLASS operand is not 
specified, the default is "*". 

KEEP=holdslot 

is a decimal number from zero to 16 which designates the 
number of virtual storage file tag slots to be reserved for 
exclusive use by the link. If the KEEP operand is omitted, a 
default "holdslot" value of two is assumed. 

LINE=vaddr 

designates the virtual device address of a permanent 
telecommunications line port to be used for processing files 
on the link. If the LINE operand is omitted, the default is 
"undefined". 

TASK=taskname 

is a one— to four-character alphameric identifier. It 
specifies the task name to be used by the line driver 
associated with the link. If the TASK operand is omitted, the 
default is "undefined". 
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I CREATING THE LAXLINES COPY FILE 

I The LAXLINES CCPY file defines the virtual device addresses of the 
! telecomaunications line ports (attached to the RSCS virtual machine) 
I which may be shared among the various active links. Such line ports 
I must be switchable, and the links which are to use these line ports must 
I have switched line ports available at their remote stations. 

I The LAXLINES COPY file consists of a list of GENLINE macro 
I statements, one for each line port. The format of the GENLINE macro is 
I as follows: 



I I 1 

I I GENLINE I LINE=vaddr | 

! I ^_^-^ .-,. 8 



I LINE=vaddr 

I is the virtual device address of a switched telecommunications 

I line port available to RSCS. 



I CREATING THE TAGQDEUE COPY FILE 

I The TAGQDEUE COPY file specifies the total number of virtual storage tag 
I slots to be available to RSCS. The format of the GENTAGQ macro is: 



I 1 1 

I I GENTAGQ | NUM=totslots | 

I L 1 



I ]!fe§I§ • 



tu — J.^4.~'! ~4.— 



j nun— uu ta J.U ua 

I is a decimal number from 32 to 512 that defines the total 

I number of virtual storage tag slots to be made available to 

I RSCS for storing information on files enqueued for 

I transmission or received from remote stations. Files which 

I cannot be enqueued for transmission because no free virtual 

I storage tag slots are available are left pending, and are 

I automatically accepted and enqueued at a later time as virtual 

I storage tag slots become available. 

I You must specify a number for totslots that is at least as 

I large as the sum of linkid tag slots defined or implied by the 

I KEEP=holdslot operand of all the GENLINK macros. 



I GENERATION PRCCEDURE FOR RSCS 

I Before you perform the generation procedure, be sure you have the 
I following: 

I • The VM/370 PLC tape 

I • A VM/370 directory entry for your RSCS virtual machine 
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I • A VM/370 directory entry for the software system support virtual 
I machine (for example, the MAINT entry supplied with the VM/370 
I starter system directory) . 

I Also, be sure that the PLC tape containing RSCS was applied to your 
I VM/370 system. 

I You can use a 2314, 3330, or 33U0 disk as the RSCS system disk. The 
I RSCS nucleus occupies two cylinders on a 2314 or 3340, and one cylinder 
I on a 3330 disk. 

I The following system generation procedure for RSCS assumes you have 
I the MAINT virtual machine supplied with the VM/370 starter system jLn 
I your VM/370 directory. 



I STEP 1. LOG C» AS MAINT AND IPL CMS 

I To build the RSCS nucleus, you must log on the software system support 
I virtual machine (MAINT) and IPL the CMS system. 



I STEP 2. ATTACH AND LOAD THE PLC TAPE 

I Mount the PIC tape, if it is not already mounted. Then you must attach 

I the real tape drive to your CMS virtual machine (MAINT). For example: 

I attach 280 to maint as 181 

I The PLC tape must be at address 181 because the VMFBLD EXEC procedure 

I expects to find it at that address. 

I With the 191 minidisk that belongs to MAINT accessed as your A-disk, 

I rewind and load the tape: 

I cp rewind 181 
i tape load 

I CMS responds with the following message: 

I LOADING... 

I VMFBLD EXEC A 

I END-OF-FILE OR END-OF-TAPE 



I STEP 3. INVOKE VMFBLD TO LOAD THE RSCS FILES 

I Access the 191 minidisk belonging to MAINT as the C-disk and invoke 

I VMFBLD: 

I access 191 c 
I vmfbld rscs 

I The VMFBLD EXEC procedure prompts you with the message: 

I ENTER CP STAGING AREA DISK ADDRESS: 
I 194 
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You respond with 194, The 194 minidisk is the area where the RSCS 
object files are to be loaded. VKPELD nest loads all the RSCS test 
files and the DMTSYS ASSEMBLE file, as well as all the control files and 
macro libraries needed to generate the RSCS nucleus, onto the 194 
minidisk. 

When all the RSCS files are loaded, VMFBLD displays the message: 

DO YOu WISH TO BUILD RSCS SYSTEM — RESPOND (YES | NO) 

You must respond "no" at this time. 

STEP 4. FORMAT THE RSCS SYSTEM DISK 

You must link to the RSCS system disk and format it. If you used the 
suggested VM/370 directory entry for the RSCS virtual machine, your LINK 
command is: 

link to rscs 191 as 195 w pass= password 

This makes the RSCS system disk (address 19 1 in the RSCS virtual 
machine) available at virtual address 195 in the MAINT virtual machine. 
Remember the address you specify for MAINT. You must use this same 
virtual address later in the RSCS generation procedure (you use 195 when 
you invoke VMFBLD again to build the RSCS nucleus in Step 8). Then, 
format the RSCS system disk. 

format 195 a 

Nest, format the RSCS system disk again. You must use the recompute 
function of the FORMAT command to make the last cylinders of the RSCS 
system disk unavailable to the CMS file system. The last one or two 
cylinders contain the RSCS nucleus. If the RSCS system disk is a 2314 
or 3340, the last two cylinders are needed for the nucleus. For a 3330, 
only the last cylinder is needed. The FORMAT command for a 2314 or 3340 
RSCS system disk is: 

format 195 a 3 (recomp 

The FORMAT command for a 3330 RSCS system disk is: 

format 195 a 4 (recomp 



STEP 5. CREATE THE COPY FILES THAT DEFINE YOUR RSCS SYSTEM 

You can use the CMS Editor to create the three COPY files you need: 
AXSLINKS, LAXLINES, and TAGQUEUE. The macros you need to include in 
these files are described in a preceding section, "Defining Your RSCS 
System." 

When you code the GENLINK macros for the AXSLINKS COPY file, you may 
include GENLINK macros with no operands. These macros reserve estra 
link table entries which can be defined later with the RSCS DEFINE 
command. Also, the local linkid (local location ID) must be specified 
on the first GENLINK macro in the AXSLINKS file. 

When you code the GENTAGQ macro for the TAGQUEUE COPY file, remember 
that the total number of tag slots must be egual to or greater than the 
number of holdslots defined either esplicitly or implicitly in the 
AXSLINKS COPY file. 
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The following exaiple shows the creation of the AXSLIHKS, LAXLINES, 
and TAGQOEOE COPY files: 

edit axslinks copy 

MEW FILE: 
EDIT: 
input 
INPUT: 

* copy axslinks 

genlink id=Bylocid,type=ditnpt 

genlink id=newyork,class=a,keep=2,line=079,task=i1,type=dmtnpt 

genlink id=sanf ran, class=a ,keep=2 , line=07a , task=i2 , type=dBtsBl 

genlink id=london ,class=a,keep=4,line=07b,type=dBtsBl 

genlink 

genlink 

genlink 

EDIT: 

file 

R; 

On the TYPE operand, DHTNPT refers to the NonprograBBable TerBinal (HPT) 
line driver prograB and DMTSHL refers to the Spool HOLTI-LEAVIHG (SHL) 
line driver prograB. 

edit laxlines copy 

NEW FILE: 

EDIT: 

input 

INPUT: 

* copy laxlines 
genline line=079 
genline line=07a 
genline line=07b 
genline line=07c 
genline line=07d 
genline line=07e 
genline line=07f 

EDIT: 
file 

R; 

edit taggueue copy 

NEW FILE: 

EDIT: 

input 

INPUT: 

* copy taggueue 
gentagg nuB=32 

EDIT: 

file 

R; 



STEP 6. CREATE DMTLOC MACRO LIBRARY 

Using the COPY files created in Step 5, generate a CMS nacro library 
called DMTLOC MACLIB, as follows: 
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maclib gen dmtloc axsllnks laxlines tagqueue 

If you must change your RSCS configuration at a later time, you have 
to change the COPY file and then generate a new DHTLOC macro library. 



STEP 7. ASSEMBLE THE CONFIGDRATIOH TABLE (DMTSYS) 

Before you assemble the configuration table module, access the CP system 
disk (194) as an extension of the RSCS system disk. 

access 19U b/a 
DaSACC723I B (194) R/0 

How, assemble the RSCS configuration table module (DMTSYS) using the 
?MFASH EXEC procedure. Specify DMTR20 as the control file. This 
control file identifies DMTLOC as the macro library to be used during 
the assembly. The DMTR20 control file is supplied on the PLC tape and 
was loaded onto the 194 minidisk in Step 3. Invoke VMFASM as follows: 

vmfasm dmtsys dmtr20 

Bote; If an error occurs due to an incorrectly coded macro, correct the 
macro and restart at Step 6. 



STEP 8. INVOKE VMFBLD TO CREATE THE RSCS NUCLEUS 

Access the 191 minidisk belonging to HAINT as the C-disk and invoke 
VMFBLD as follows: 

access 191 c 
vmfbld rscs build 

The VMFBLD EXEC procedure prompts you with the message: 

ENTER CP STAGING AREA DISK ADDRESS: 
194 

You respond with 194. The 194 minidisk contains all the RSCS files; 
they were loaded in Step 3. 

VMFBLD next prompts you for the operands it needs to link to the RSCS 
system disk: 

ENTER RSCS SYSTEM DISK LINK PARAMETERS: 
USERID VADDR1 VADDR2 

If you are following the examples in this procedure, you enter 

rscs 191 195 

The value you enter for vaddr2 must be the same value you specified for 
vaddr2 on the LINK command issued in Step 4; otherwise, the link is not 
allowed. The userid you specify is the userid of your RSCS virtual 
machine and the virtual address you specify for vaddrl is the virtual 
device address of the RSCS system disk in the RSCS virtual machine. 

VMFBLD then links to the RSCS system disk and copies four files 
(DMTHPT, DMTSML, DMTAXS, and DMTLAX) to it. You receive the following 
message: 
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TRANSFEBBING 'RSCS* DISK BESIDENT TEXT 

Finally, VMFBLD builds and loads the BSCS nucleus. You receive the 
following messages: 

DMTINm07R REWRITE THE NUCLEUS ? yes 

DMTINI408R IPL DEVICE ADDRESS = 195 

DMTINI409B NUCLEUS CYL ADDBESS = 003 (or, 004 for a 3330) 

DMTINIU10B ALSO IPL CYLINDER {YES|NO) ? yes 

For this example, respond as shown. You respond with the address of the 
RSCS system disk, in this case 195. You always respond with the same 
address you specified as vaddr2 when you were prompted for link 
parameters. The nucleus cylinder address depends on the device type of 
the RSCS system disk. 

You receive the message 

DMTAXS103E FILE 'spoolid* REJECTED — INVALID DESTINATION ADDBESS 

This message reflects the purging of the BSCS nucleus from the card 
reader. 

At this time you have an RSCS system generated and written to the 
RSCS system disk, as indicated by the message: 

DMTREXOOOI RSCS (VEB 1, LEV 1, mm/dd/yy) BEADY 

You can now log on the BSCS virtual machine, IPL the BSCS system disk 
and start your RSCS operations. See the VM/JVO: Remote Spooling 
Communications Subsystem (RSCS) User^s Guide for information about using 
BSCS. 
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If you do not want to support a 3704/3705 control program under VM/370 
control, disregard Part 4. 

Part 4 describes the procedures you must follow to generate, test, 
and run a 3704/3705 control program with Vm/370. It includes the 
following inforiation: 

• Introduction 

• Planning Considerations 

• Generating and Loading the 3704/3705 Control Program 

• Testing the 3704/3705 Control Program 

You should generate a VM/370 system that supports the 3704/3705 
first. "Part 1: Planning for System Generation" contains a section, 
"Generating a VM/370 System that Supports the 3704 and 3705," that tells 
you what you must include in your VM/370 system. When you have a VM/370 
system that supports the 3704/3705, use the information in this part to 
generate and test a 3704/3705 control program that runs under VM/370 
contol. 
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The IBM 370U and 3705 Communications Controllers are programmable 
units. One of three programs can be generated to execute in 370U/3705 
storage : 

1. Network Control Program (NCP) performs many of the teleprocessing 
line-control and line-servicing functions previously performed by 
the central processing unit. 

2. Emulation program (EP) permits existing teleprocessing systems, 
including VH/370, that use the IBM 2701, 2702, or 2703 Transmission 
Control Units or the Integrated Communications Adapter (ICA) of the 
System/370 Model 135, to execute without change on the 3704/3705. 

3. Partitioned Emulation Program (PEP) allows the 3704/3705 to be 
divided so that both the NCP and EP can execute in one 3704/3705. 

In this publication, the term "3704/3705 control program" refers to 
any of the three types of control programs: NCP, EP, or PEP. 

VM/370 supports both the: 

• IBM 3704 Communications Controller, Models A1-A4 

• IBM 3705 Communications Controller, Models A1-D8 

when attached to an IBM System/370 Model 135, 145, 155 II, 158, 165 II, 
or 168. Three terminals are supported: 1050, 2741, and CPT-THX 33/35. 
The 3767 terminal (operating as a 2741) is not supported by lines in NCP 
mode. You can generate any of three kinds of 3704/3705 control programs 
(NCP, EP, or PEP) to execute under VM/370. 

The minimum amount of 3704/3705 storage reguired for a NCP or PEP 
control program is 48K; the minimum required by an EP control program is 
16K. 
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Planning Considerations 



When planning for the installation of IBM 370U and 3705 Communications 
Controllers, be sure that you are familiar with device characteristics, 
have the the appropriate publications and support package, and have a 
VM/370 system that supports the 3704/3705. 



RJI-ATEp PUBLICATIONS 

The Introduction to the IBM 3704 and 3705 Communications Controllers, 
Order No. GA27-3051, describes the general functions of the 3704 and 
3705. It is a prerequisite publications for generating a 3704/3705 
control program under VM/370. 

If you are installing Version 2 of the Network Control Program/VS, 
the IBM 3704 and 3705 Communications Controllers, Network Con tr ol 
HfSaiSlZys Generation and Utilities Guide and Reference Manual (for 
QS/VS~and DOS/VS TCAM Users) , Order No. GC30-3007, is a corequisite 
publication. If you are installing Version 3 of the Network Control 
Program/VS, the IBM 3704 and 3705 Communications Controllers, Network 
Control Program/VS Generation and Utilities, Guide and Reference Manual 
(f2£ OS/VS and DOS/VS VTAM Users), Order No. GC20-3008, is a corequisite 
publication. You must refer to one of these publications in order to 
code the 3704/3705 control program generation macros. Throughout Part 
4, these publications are referred to as the 3704 and 3705 Generation 
and Utilities Guide. 



3704 AND 3205 SUPPORT PACKAGE 

Before you can generate a 3704/3705 control program, you must have one 
of the following OS/VS Network Control Program Support packages. These 
are the only 3704/3705 support packages that contain the CMS file 
required for generating and loading 3704/3705 control programs under 
VM/370. The two support packages are: 

• IBM 3704/3705 Network Control Program Support Package for OS/VS 

(Order No. 5744-BA1). VM/370 supports this package in network 
control, partitioned emulation, and emulation mode. 

• IBM 3704/3705 Network Control Program Support Package for OS/VS 
(Order No. 5744-BA2) . VM/370 supports this package in emulation mode 
only. 

These packages contain the following basic material: 
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DOCOHENTATION 



A Program Directory 



• IBM 370J» and 3705 Communications Controllers, Network Control 
PI23E51Z1S Generation and Utilities, Guide and Reference Manual (for 
QS/VS and DOS/VS TCAM Users), Order Ho7 GC30-3007 

I — or — 

I ill! 3704 and 3205 Communications Controllers, Network Control 
I Iloaram^VS Generation and Utilities, Guide and Reference Manual (for 
I OS/VS and DOS/VS VTAM Users) , Order No. GC30-3008 

I • im 320U Control Panel Guide, Order No. GA27-3086. 

I • IBM 3705 Control Panel Guide, Order No. GA27-3087. 



Maching Readable Material 

• Magnetic tape containing the macros and modules of the 3704/3705 
control program and the OS/VS system support programs. 



VMZ370 SUPPORT OF THE 3704 AND 3705 

The IBM 3704/3705 Communications Controllers can support: 

• Up to 352 low-speed start-stop lines 

• Up to 60 medium-speed synchronous lines 

• Line speeds from 45.2 baud to 50. OK baud 

• Modem capability within the 3704/3705 

• Limited-distance "hard-wire" capability 

• 16K to 240K internal storage 

I • Remote 3277 and 3275 terminals with optional 3284, 3286, and 3288 
I printers 

VM/370 supports all three versions of the 3704/3705 control programs: 

• Emulation Program (EP) 

• Network Control Program (NCP) 

• Partitioned Emulation Program (PEP) 

VM/370 's support of the 3704/3705 does not include: 

• Remote 3704/3705 Communications Controllers 

• Binary synchronous terminals (However, the 2780 is supported when it 
is attached to an emulator mode line.) 



EMULATION PROGRAM (EP) WITH VM/370 

The EP 3704/3705 control program under VM/370: 

• Emulates 2701, 2702, and 2703 operations 

• Attaches to a System/370 byte multiplexer channel 
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• Supports up to 255 start-stop lines 

• Supports up to 50 medium-speed synchronous lines 

This support is equivalent to that provided in Release 1 of VB/370. 
The CP DIAL command and the TERMINAL APL ON and APL OFF command lines 
are supported. However, Release 2 of VH/370 provides additional support: 

• Service programs and special CMS commands allow you to easily 
generate the EP control program in a CMS virtual machine. 

• The CP NETWORK command allows you to load or dump the 3704/3705 and 
provides for automatic dumping and reloading if a fatal error 
occurs. 



NETWORK CONTROL PROGRAM (HCP) WITH VM/370 

The NCP 370U/3705 control program under VM/370 provides: 

• A device-independent EBCDIC interface 

• Communications line control handling 

• Attachment to a System/370 byte multiplexer, block multiplexer, or 
selector channel 

• Block and character checking 

• Block and message buffering 

• Assembly and disassembly of multiple-block transmissions 

• Line error recovery procedures 

• Checkpoint/restart switching to a backup processor 

• User-written message processor routines 

However, when an NCP 3704/3705 control program is under the control 
of VM/370: 

• The CP DIAL command is not supported. 

• The CP TERMINAL APL ON or APL OFF command line is not supported. If 
you issue the TERMINAL APL ON command at a terminal that is connected 
to VM/370 on a 3704/3705 line in NCP mode, you cannot execute your 
program and may have to IPL again to continue. 

• NCP resources cannot be shared between VM/370 (the Control Program) 
and the virtual machines. A virtual 3704/3705 or 2701/2702/2703 is 
not supported. 

• special sign-on procedures are required (1) if you have the Multiple 
Terminal Access feature generated for your NCP control program and 
(2) if you have a 2741 terminal on an NCP-mode line. These 
procedures are described in "Step 11. Logging On Through the 
3704/3705 Control Program" of the "Generating and Loading the 
3704/3705 Control Program" section. 

A VM/370 nucleus that supports the NCP version of the 3704/3705 
control program is smaller than one that supports the EP or PEP 
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versions. Each line in NCP mode requires U8 bytes of free storage while 

oikf-h lino in emnla + rsT- nir-.i^<2 rartn-ir-ae: fi(\ l-,w+ jao /-.-f Il"r'1 



PARTITIONED EMULATION PROGRAM (PEP) WITH VM/370 

The PEP 3704/3705 control program under Vn/370: 

• Combines the 2701/2702/2703 Emulation Program and the Network Control 
Program 

• Allows for the concurrent use of NCP and emulator interfaces 

• Provides for programmable switching of lines between NCP mode and 
emulator mode 

If you execute a PEP control program under the control of VM/370, you 
should know that: 

• The CP DIAL command is supported for lines generated as emulator 
lines and lines generated to vary between emulator mode and NCP 
mode. If the DIAL command is issued for a line that may be varied 

(and, if that line is currently in NCP mode), that line is 
automatically varied to emulator mode. 

• The TERMINAL APL ON or APL OFF command line is supported only for 
lines currently in emulator mode. 

• Only 3704/3705 lines in emulator mode may be dedicated. 
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Generating and Loading the 3704/3705 Control Program 



Several coaiands and EXEC procedures generate and load the 37p4/3705 
control prograa. These coamands and EXEC procedures execute in a CHS 
virtual machine. The coonands are a part of the VH/370 system and are 
distributed with it. 

A special version of the IBM 3704/3705 network Control Program 
I Support Package for OS/VS, Order »o. 5744-BA1 for Version 2 and Order 
I No. 5744-BA2 for Version 3, is available from PID for use under VH/370. 
These versions of the 3704/3705 package contains two CMS EXEC procedures 
for generating and loading the 3704/3705 control programs that are not 
available in the standard OS/VS 3704/3705 support package. Order No. 
5744-AN1. 

This section describes the step by step procedure for generating and 
loading the 3704/3705 control program. Each EXEC procedure and command 
is described as it is used. The action reguired at each step is 
summarized first and then explained in detail. The preceding "Planning 
Considerations" section, lists all the documentation, physical devices, 
programming, and other materials you need to have available before 
starting to generate the 3704/3705 control program. 



STEP J. LOG ON THE VM/370 SYSTEM 

You must load a VM/370 system that supports a 3704/3705 control 
program. 

Release 2 of VM/370 supports the NCP, EP, and PEP types of control 
programs. The system that you load also must have been generated with: 

• The IBM 3704 or 3705 Communications Controllers specified on a 
RDEVICE system generation macro. 

• The NAMENCP macro coded to create an entry in the VM/370 system name 
table (DMKSNT) for the 3704/3705 control program. 

• Space reserved on a CP-owned volume to contain a copy of the 
3704/3705 control program. 

These VM/370 system generation reguirements are described in Part 1. 



STEP 2. SET UP A CMS VIRTOAL MACHINE 

You must IPL a CMS virtual machine and be sure that the necessary 
devices are attached. 

The 3704/3705 control program is generated using commands and EXEC 
procedures that execute in a CMS virtual machine. The CMS virtual 
machine must have the following resources: 

• At least 1024K of virtual storage. 

• One tape drive (9 track, 800 or 1600 bpi) . 
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• Space available on the CMS A-disk (120 cylinders of a 3330 disX, all 
203 cylinders of a 2314 disk, or 300 cylinders of a 3340 disk) . 

If the CMS virtual machine does not have these resources, use the CP 
DEFINE coanand to redefine the size of your virtual storage or send a 
■essage to the operator requesting him to attach the tape or disk device 
you need . 

or TEXT. Use the CMS BEHAHE command to temporarily change such 
filetypes. A naming conflict can terminate the installation procedure 
for the distribution tape. 

I You need CP command privileges A, B, and G to install the 3704/3705 
i control program and, if you use the NETHOBK TRACE command while testing 
I the 3704/3705 control program, you need command privilege class F. Do 
I not use class F unless you need it; for class F, I/O error recording is 
I not done automatically. Check with the system administrator to ensure 

that your VM/370 directory entry has the appropriate command 

privileges. 



STEP 3. LOAD THE IBM 3704^705 COHTHOL PROGRAM DISTRIBUTION TAPE FILES 
ONTO A CMS DISK 

Use CMS commands to position the distribution tape at the proper file 
and to create CMS disk files from the tape files. The first file 
created from the tape files is an EXEC procedure that processes the rest 
of the tape files and creates the CMS disk files. 

If you cannot mount the distribution tape yourself, send a message to 
the operator and have him mount the correct tape. The distribution tape 
contains six files. The fifth file is the LOADCC EXEC procedure which 
creates the necessary CMS files from the other tape files. 

Use the CMS TAPE command to position the tape at the beginning of the 
fifth file: 

tape fsf 4 

Then, use the CMS TAPPDS command to create the LOADCC EXEC A1 file from 
the fifth file: 

tappds * exec 
If the file is successfully created, the response 

FILE 'LOADCC EXEC A1' COPIED 

appears on the terminal. 

Invoke the LOADCC EXEC procedure to load all the necessary files and 
generate the 3705 Assembler: 

loadcc 

The LOADCC EXEC procedure creates the macro and text libraries, and 
generates the 3705 Assembler, that are needed to generate a 3704/3705 
control program. The LOADCC EXEC procedure sends messages to the 
terminal to indicate its progress. 
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LOADCC issues the message 

BOILD STAGE ONE MACLIB NCPGEN 

and uses the second tape file to create the CMS file, NCPGEN MACLIB A1. 
It issues a second message 

BUILD STAGE TWO MACLIBS NCPMAC01 HCPMAC02 

and uses the third tape file to create the CMS files, NCPMAC01 MACLIB A1 
and NCPMAC02 MACLIB A1. Using the fourth tape file, LOADCC creates the 
CMS file, OBJ3705 TXTLIB A1 , after issuing the message 

BUILD STAGE TWO TXTLIB OBJ3705 

Finally, LOADCC issues the message 

BUILD 3705 ASSEMBLER ASM3705 

and creates two files, ABNGEND EXEC A1 and ASM3705 TXTLIB A1, from the 
sixth tape file. The ARNGEND EXEC procedure is invoked by LOADCC to 
generate the 3705 Assembler. The ASM3705 TXTLIB A1 file is used to 
generate the 3705 Assembler. 

When the last message 

END OF INSTALLATION 

appears on the terminal, the distribution tape is no longer needed. At 
this time, the 3705 Assembler program, the macro libraries for the stage 
1 and stage 2 generation procedures and the text library for the stage 2 
generation procedure all exist on the CMS A-disk. 

Note: You may find it helpful to dump the contents of the A-disk to tape 
at this time. If you save the tape dump, you have the pre-Stage 1 
files. If errors are later encountered, you may need these files. 



STEP 4. CODE THE 3704^3705 CONTROL PROGRAM MACRO INSTRUCTIONS 

Code the 3704/3705 control program macro instructions and place them in 
a CMS file. Use the CMS Editor to create the file, which must have a 
filetype of ASM3705. VM/370 recommends that you assign the same 
filename to this CMS file as was specified previously in the NAMENCP 
macro. If the SAVE option is to be specified on the GEN3705 command, 
the filename must be the same. This ASM3705 file is used as input to 
Stage 1 of the 3704/3705 control program generation procedure. 

Use the 3704 and 3705 Generation and Utilities Guide to code the 
macro instructions. Follow the macro instruction formats described in 
that publication except where suggestions and requirements are indicated 
in the following paragraphs. 

Do not code the following macro instructions for an NCP 3704/3705 
control program that executes under the control of VM/370: 

BHSET ENDBH 

CLUSTER lOLIST 

COMP LINELIST 

DATETIME SERVICE 

DIALSET STARTBH 

EDIT UBHR 
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BUILD MACRO INSTRUCTION 



The BUILD macro must be the first macro in the CMS file. Figure 23 
lists the operands which VM/370 requires, recommends, and does not 
support. It also indicates (in parentheses) which of the three types of 
3704/3705 control programs support each of the operands. For all other 
operands, refer to the 3704 and 3705 Generation and Utilities Guide. 



{Operand ! Comments 


1 LOADLIB=dsname j Required by the BUILD macro, but does not 
|OBJLIB=dsname | apply to VM/370. Specify a valid dsname. 

1 1 (NCP, PEP, and EP) 

1 . . „. 


|ABEND= fYES^ | VM/370 recommends ABEND=YES be specified. 
1 iNO / 1 (NCP and PEP only) 

1 „ . , _ „ . ,., 


|ANS=JYES\ 1 VM/370 recommends ANS=NO be specified. 
1 (NO / 1 (NCP and PEP only) 

1 , , , , 


|ASMXREF=/YES) | VM/370 recommends ASMXREF=YES be specified. 
1 (NO / 1 (NCP, PEP, and EP) 

1 , . , , , 


1 . — , ... , 

|BFRS=rsiZE) 1 VM/370 recommends BFRS=68 be specified. 

1 (60 / 1 (NCP and PEP only) 

1 „ ., .... 


|CHKPT=rYES) 1 VM/370 ignores these operands. 
1 (NO / 1 (NCP and PEP only) 

t 1 

|CSMHDR=chars | 
|CSMHDRC=chars | 
|CSMMSGC=chars | 
1 


|CUID=chars | VM/370 does not support these operands. 
|DIALTO=r county | (NCP and PEP only) 
! |60^0 ] ! 
1 


|ERASE=r YES)^ | VM/370 recommends ERASE=YES be specified. 

1 (NO j 1 (NCP AND PEP only) 
1 , , 


|ITEXT0=rC0UNT\ | VM/370 requires the default value. 
1 (NONE / 1 (NCP and PEP only) 

1 ..,,., 


1 (YES ) 1 VM/370 recommends JOBCARD=MULTI. 
1 JOBCARD=<^NO > 1 (NCP, PEP, and EP) 

1 (multi) 1 

1 , . , .. .. , . ., 


|MTARTRY=/C00NT) I VM/370 recommends MTARTRY=16 be specified. 
1 ( j 1 (NCP and PEP only) 
1 1 



Figure 23. BUILD Macro Operands for VM/370 (Part 1 of 2) 
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_ _ — ^ 

Operand | Comnents I 


(NCP001 ) 1 VM/370 requires that the value of HEWNAME be | 
HEHNAME=< PEP001 > | the same as the name previously specified | 

(symbol ) | in the HAHEHCP macro and the name that | 
1 subsequently will be specified in the | 
1 SAVEHCP command. Also, if the GEN3705 | 
1 command is to be issued with the SAVE | 
1 option, the value of MEMHAME must be the | 
1 same as the "fname" specified on the | 
1 6EH3705 command. | 
1 (NCP, PEP, and EP) I 


OLT=f¥ES) 1 VM/370 recommends OLT=NO be specified. | 
IHO / 1 (NCP and PEP only) 1 


PNLTEST=f YES) | VM/370 recommends PNLTEST=YES be specified. | 
iHO / 1 (NCP, PEP, and EP) I 


(symbol] | VM/370 requires the default value. | 

QUALIFY=<^NONE > | (NCP, PEP, and EP) 1 

(SYSJ ) 1 1 


(r r ■«■« ) 1 VM/370 recommends that TRACE=YES be | 

TRACE=nNO |,jSIZEl||f | specified. 1 

)|YES| tlO jl 1 ( 1 (NCP, PEP, and BP) I 


UT1=dsname | VM/370 ignores these operands. j 
0T2=dsname | (NCP, PEP, and EP) 1 
UT3=dsname | j 


XBREAK=| integer) | VM/370 requires that XBREAK be specified | 

(NONE / 1 with a minimum value of 3. I 

1 (NCP and PEP only) I 


XITB=|YES) 1 VM/370 does not support this operand. | 
(NO j 1 (NCP, PEP, and EP) 1 



Figure 23. BUILD Macro Operands for VM/370 (Part 2 of 2) 



I CSB MACRO INSTRUCTION 



I The CSB macro instruction is required. See the 3704 and 3705 Generation 
I 55^ Utilities Guide for more information about coding the CSB macro 
I instruction. 



SYSCNTRL MACRO INSTRUCTION 



The SYSCNTRL macro instruction specifies which of the dynamic control 
features are to be included in the 3704/3705 control program. SYSCNTRL 
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applies to only HCP and PEP 3704/3705 control programs. The minimum 
options required by VM/370 are: 

SYSCNTRL OPTIONS=(LTRACE, 

STORDSP, 
MODE, 
RCOHD, 
RIHM, 
RSCKD 
RDEVQ, 
RCHTRL, 
DEACTDV, 
ACTDV) 

The other options for SYSCNTRL listed in the 3704 and 3705 Generation 
and Utilities Guide may be specified; however, they are not recognized 
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by VM/370 and use storage unnecessarily. The DEACTDV (deactivate 
device) and ACTDV (activate device) options are not listed in the 370U 
M^ J205 Generation and Utilities Guide. Nevertheless, they are valid 
and must be specified for VM/370. 



HOST MACRO ISSTEUCTICN 
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control programs. For VM/370, it must have the following operands with 
the values shown: 



HOST 



INBFSS=4, 

DELAY=0/ 

MAXBFRU=6, 

UNITSZ=96, 

BFBPAD= {3H,3^) , 

TIMEOUT=NONE 



For a PEP 3704/3705 control program, the "NCPCHAN=channel address" 
operand must also be specified. 



THE MACRO INSTRUCTIONS FOR THE MULTIPLE TERMINAL ACCESS (MTA) FEATURE: 
MTALCST, MTALIST, MTAPOLL, MTATABL, AND GROUP 

VM/370 recommends that you use the NCP Multiple Terminal Access (MTA) 
feature. This feature allows the 3704/3705 control program to accept 
switched-line connections for any of several terminal types, on the same 
physical line interface. The 3704/3705 control program determines the 
terminal line code and line speed when the switched connection is 
initially established, and passes the terminal type to the host access 
method. 

The MTA feature of the NCP supports 1050, 2741, CPT-TWX, 2740-1, and 
2740-2; however, VM/370 supports only 1050, 2741, and CPT-TilX 33/35 
terminals. Therefore, do not specify the 2740-1 or 2740-2 devices on 
any of the MTA macros for a 3704/3705 control program that executes 
under VM/370. The 3704 and 3705 Generation and Utilities Guide, 
contains all the information you need to code the MTA macro; however, 
use Figure 24 when coding the LCTYPE operands. 



Macro I 



Operand 



Comments 



MTALCST 



MTALIST 



MTATABL 



LCTYPE=(1050 
^2741 
JTWX 



LCTYPE= (type,...) 

where : 

type may be 1050, 
2741, or THX. 



LCTYPE=(J050 
<^2741 

(twx 



VM/370 does not support 2740A, 2740D, 
2740E, or 2740F specifications for the 
LCTYPE operand. 



Figure 24. LCTYPE Operands for MTA Macros with VM/370 
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Figure 25 shows valid MTA macros for a 3704/3705 control program to 
be executed with VM/370. The first set of macros (labeled MASTER 
through MTELE) describes an actual hardware configuration. Along with 
this set of macros, it is necessary to specify TERM=MTA on the GROUP, 
LINE, and TERMINAL macros; and to specify MTALIST=MASTER on each LINE 
macro to be used with MTA. The second set of macros (labeled FAKE2741, 
FAKE1050, and FAKETTY) describes a software configuration, a 
configuration with no lines. 



MTA Macros 



Comments 



MASTER MTAIIST LCTYPE= (27U 1 , TWX, 1 050) 



M2741E MTALCST 



M2741C MTALCST 



M1050E MTALCST 



MTELE MTALCST 



MTATABL 
MTATABL 
MTATABL 
MTATABL 



GROUP=FAKE27ai,SPEED=13a, 
LCTYPE=27U1 ,CLOCKNG=INT, 
CODE=EBCD 

GROUP=FAKE274 1, SPEED= 134, 

LCTYPE=27U1,CL0CKNG=INT, 

CODE=COR 

GROUP=FAKE1050,SPEED=134, 

LCTYPE=1050,CLOCKNG=INT, 

CODE=EBCD 

GROUP=FAKETTY,SPEED=110, 
LCTYPE=TWX,CLOCKNG=INT 

LCST=M2741E,CODE=EBCD,LCTYPE=27U1 
LCST=M2741C,CODE=COR,LCTYPE=27m 
LCST=M1050E,CODE=EBCD,LCTYPE=1050 
LCST= MTELE, LCTYPE=TWX 



Master selec- 
tion list 

PTTC/EBCD 2741 



Correspondence 
2741 



Standard 1050 



ICPT-TWX 33/35 



MTAPOLL POLL= (61F0) 



FAKE2741 GROUP DIAL=YES,LNCTL=SS,TYPE=NCP, TERM=2741 
FAKE1050 GROUP DIAL=YES,LNCTL=SS,TYPE=NCP,TERM=1050 , 

POLLED=YES 
FAKETTY GROUP DIAL=YES,LNCTL=SS ,TYPE=NCP ,TEBB=TWX 



1050 common 
polling char- 
acteristics 



Figure 25. Example of MTA Macros for Use with VM/370 



If, for multiple terminal access support, it is necessary to define a 
standalone line group (a GROUP macro followed by no LINE and TERMINAL 
macros) , specify the following operands in the GROUP MACRO: 

DIAL=YES 

LNCTL=SS 

TERM=1050 (TWX or 2741) 

POLLED=YES (only if you specify TERM=1050) 

All other LINE and TERMINAL operands are invalid for a standalone 
line group and, if coded, are ignored. 
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GROUP, LINE, AMD TERMINAL MACRO INSTRUCTIONS 
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VM/370 reguires the ATTN, MONITOR, DUPLEX, and FEATURE operands. 
These operands allow VM/370 to detect and respond to a terminal 
attention interrupt and to recognize when a data set has been hung up. 
The CRDLAY operand is recommended because it prevents typing when the 
terminal carriage is returned. POLLED=YES is reguired for any 1050 
device. For the GROUP macro, VM/370 reguires the default value for the 
REPLYTO operands and recommends the default value for the TEXTTO 
operand. The macros shown in Figure 26 describe a sample Network 
Control Program configuration without PEP support. 



r 


- 


■~" 


. .. 


1 ... 1 ... 1 . 1. 


1 Configuration 


Macros 




1 Comments 


1 FIRST 


GROUP 


DIAL=YES, 
LNCTL=SS, 
SPEED=13U, 




I 






MTALIST=MASTER 


r 


MTA in use, see Figure 25 






TERM=MTA, 




1 






CRDLAY=YES, 




Prevents typing while carriage 






CDATA=YES, 




I is in motion 






ATTN=ENABLED, 




Reguired 






DUPLEX=FULL, 




Reguired 






FEATURE=(ATTN, 


BREAK) , 


Reguired 






MONITOB=YES, 




Reguired 






POLLED=YES 




Reguired for 1050 


1 LINE20 


LINE 


ADDRESS=020 




First line, base module 


1 TERM20 


TERMINAL 


TEBM=MTA,CTERM 


= YES 


Logical connection base 


1 LINE21 


LINE 


ADDRESS=021 






1 TERM21 


TERMINAL 


TERM=MTA,CTERM 


= YES 





Figure 26. Example of Configuration Macros for Use with VM/370 

Although the SPEED operand specifies 134.5 bps, the MTA feature is 
able to recognize a CPT-TWX terminal, and has the ability to change the 
oscillator rate to the reguired 110 bps. However, the MTA feature 
cannot be used to intermix CPT-TWX with 1050 or 2741 terminals unless 
the hardware communications scanner (s) have both the 134.5 bps 
oscillator and the 110 bps oscillator. 

GENEND MACRO INSTRUCTION 

The GENEND macro indicates the end of the 3704/3705 macro input file. 
It must be the last record in the CMS file you are building as input to 
Stage 1. 
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SPECIAL MACRO CODING CONSIDERATIONS FOR THE PARTITIONED EMULATION 
PROGRAM (PEP) 

The PEP control program coibines the 2701/2702/2703 Eiulation Program 
with the HCF. In some cases, both the emulator and the NCP macro 
operands must be specified in the Stage 1 input file. Code all the 
macros as though you were generating an NCP control program. Then, add 
the additional emulator operands which are required. For the BOILE 
macro, the emulator operands HICHAN, LOCHAN, and TyPGEH=PEP are 
required. For the HOST macro, an additional operand, NCPCHAN, is 
required to specify which subchannel address is to be used for 
communication with the NCP portion of PEP. The SYSCNTRL macro is 
unchanged. 

The MTA facility can be used with only the NCP; and only with NCP 

resources that cannot be varied to emulation mode. ihenever MTA 

operands are specified for lines that can be varied, errors result in 
the Stage 1 assembly. 



SPECIAL MACRO CODING CONSIDERATIONS FOR THE EMULATION PROGRAM (EP) 

There are no strict dependencies between the host access method and the 
emulation program; consequently, few guidelines are necessary for an 
emulation program generation. However, be careful when configuring 
emulator lines for CPT-TWX terminals. While VM/370 normally accepts 
incoming calls from either 1050 or 2741 terminals on the same physical 
line, that same line cannot be used for CPT-TWX terminals. When 
generating the VM/370 system, ensure that the hardware configuration 
specified in the CP module DMKRIO matches the configuration of the 
Emulation Program for CPT-TWX lines; the exact configuration of 1050 and 
27U1 lines is not critical. 

Note; The base address of the 3704/3705 (the address used to load and/or 
dump the control program) can never be specified for use as a 
telecommunications line. VM/370 treats the base address as a separate 
entity for use only during the load and dump operation. 



STEP 5. DEFINE THE MACHO AND TEXT LIBRISIIS 

The macro and text libraries created from the distribution tape in Step 
3 must be made available to CMS. One macro library (NCPGEN) is needed 
for the Stage 1 generation procedure and two macro libraries (NCPMAC01 
and NCPMAC02) and one text library (OBJ3705) are needed for the Stage 2 
generation procedure. It is easiest to define all the libraries before 
starting Stage 1. Use the CMS GLOBAL command; 

GLOBAL MACLIB NCPGEN NCPMAC01 NCPMAC02 
GLOBAL TXTLIB OBJ3705 



STEP 6. THE STAGE 1 GENEJ4II0N IJOCEDURE 

The Stage 1 generation procedure accepts the CMS file you created in 
Step U as input and produces the Stage 2 input file that is needed in 
Step 7. 
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The Stage 1 generation procedure is performed by invoking the 3705 
Assembler to process the 3704/3705 control program macro instructions. 
It produces one file with the same filename as the input file and with a 
filetype of TEXT. This TEXT file contains 3705 Assembler source 
statements and job control language (jcl) statements. 



THE ASM3705 COMMAND 



Use the CMS ASM3705 command to invoke the 3705 Assembler to assemble the 

macro instruction file. The 3705 Assembler processing and output are 

controlled by the options selected. The format of the ASM3705 command 
is: 




f n [ (options. . .[ ) ]] 

options : 

r nr tt tt t r t 

IXREF I IRENT | | DECK | I LOAD | |LIST | 
INOXREFI IHORENTI |NODECK| |SCLCAD| |NOLIST| 

L JL JL JL JL J 



r T 

ILINECNT nn| 

ILINECNT 55 I 

L J 



r 1 

(PRINT I 
I DISK I 
INOPRINTI 

L J 



w h er e : 
fn 



specifies the filename of the source file to be assembled. 
This source file contains the 3704/37C5 control program macro 
instructions. The file must have a filetype of ASM3705 and 
fixed-length, 80-character records. 

Options 

If duplicate or conflicting options are specified, the last one 
entered in the command line is in effect. 

XREF includes a cross-reference symbol table in the LISTING 
file. 

NOXREF suppresses the cross-reference symbol table. 

RENT checks the source file to see if it satisfies reentrancy 
requirements. 

NORENT suppresses the check for satisfaction of reentrancy 
requirements. 

DECK spools the output object module, fn TEXT, to the punch. 

^CDECK suppresses the spooling of the output object module, fn 
TEXT, to the punch. 

LOAD creates a TEXT file on disk for the program that was 
assembled. 

NOLOAD suppresses the creation of a TEXT file on disk for the 
program that was assembled. 
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LIST produces a LISTING file. 

NCLIST produces no LISTING file. 

PRINT spools the LISTING file to the printer. 

DISK puts the .LISTING file on disk. 

NCPRINT produces no LISTING file. 

LINECNT nn 

specifies the number of lines per output printer page. A 
default of 55 lines is assumed. 



Ziles Created bj[ the ASM3705 Command 

TEMPORARY WORK FILE S : Three files are temporarily created for each 
assembly : 

fn SYSUT1 
fn SYSUT2 
fn SYSUT3 

Any existing files with the same file identifiers are erased at the 
beginning of the assembly. These files are placed on the read/write 
disk with the most available space. Work space is automatically 
allocated as needed during the assembly and returned to available status 
when the assembly is complete. Insufficient space causes abnormal 
termination of the assembly. 



OMMJNT FILES: One or two permanent files may be created during a 
successful assembly: 

fn TEXT 
fn LISTING 

The fn TEXT file contains the output object module if the LOAD option is 
in effect. The fn LISTING file contains a listing of source statements, 
assembled machine code, and other associated information based on the 
options selected. This file is created unless the NOPRINT or NOLIST 
options are selected. The LISTING and TEXT files are placed on (1) the 
disk from which the source file was read, (2) its parent or (3) the 
primary disk, disk, unless you created a file definition for these files 
placing them on a non-DASD device. Failure to obtain sufficient space 
for these files results in abnormal termination of the assembly. 



SPECIAL CONSIDERATIONS FOR THE STAGE 1 ASSEMBLY 

The Stage 1 assembly can be very lengthy. The amount of time the 
Assembler takes depends upon the macro options selected and the number 
of users on the VM/370 system. Do not be surprised if the assembly for 
an NCP control program takes over an hour. 

The LISTING file produced by the Stage 1 assembly is quite large. If 
you let the ASM3705 command option default to DISK, much of the space on 
your A-disk is used. Therefore, VM/370 recommends that you specify the 
PRINT option when you issue the ASM3705 command. Also, there are many 
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macro expansions that make the LISTING file larger. VM/370 recommends 
that you insert a "PRINT NOGEN' assembler statement in front of the 
first macro instruction in the input file to suppress the printing of 
the macro expansions and reduce the size of the LISTING file. 

You should examine the output of the Stage 1 assembly carefully and 
produce a list of resource IDs, with their characteristics, for the 
operations personnel. The cross-reference list for operations should 
include: 

• Resource ID 

• Type of resource (line or terminal) 

• Type of line (NCP-mode, EP-mode, or variable) 

• Location 



STEP 7. THE STAGE 2 GENERATION PROCEDORE 



During the Stage 2 generation procedure the TEXT file produced in Step 6 
is scanned. That TEXT file contains several job steps of 3705 Assembler 
source statements with embedded OS JCL statements. The JCL statements 
are removed and a unique CMS 3705 Assembler source file is created for 
each job step in the input file. An EXEC procedure is also created to 
assemble and link edit the source files. When the EXEC procedure is 
invoked, it produces the load module file (and, optionally, saves a copy 
of the control program in page-format on a CP-owned volume) . 



THE GEN3705 COMMAND 



Use the CMS GEN3705 command to invoke the Stage 2 service program. 
Command options let you determine whether or not GEN3705 includes a 
command in the EXEC procedure to save a copy of the load module on disk, 
or if GEN3705 invokes the EXEC procedure automatically. The format of 
the GEN3705 command is: 



I GEB3705 

I 

I 

h 

I 

I 

I 



fname ftype [fmode] [ (options. ..[)] ] 

Options : 

r n r t 

|RUN I ISAVE I 
I S ORU N I I NO SAVE | 

L J L J 



whe re ; 
fname 



specifies the filename of the Stage 2 input stream produced by 
the Stage 1 assembly. The file must contain fixed-length, 
80-character records. 



ftype specifies the filetype of the Stage 2 input stream, 
filetype is normally TEXT. 

fmode specifies the filemode. 



The 
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0£t ions : 

If duplicate or conflicting options are specified, the last option 
entered on the comiand line is in effect. 

RUN causes the output EXEC file to be executed at the 
conclusion of the Glli3705 processing. 

J?CRD5 suppresses the execution of the output EXEC file. 

SAVE includes a SAVENCP command in the output EXEC file to 
create a page-format copy of the 370M/3705 control program 
on a VM/370 CP-owned volume. 

HOSAVE does not include the SAVENCP command in the output EXEC 
file. 



Files Created bi the GEN3705 Command 

Three types of permanent files are created when the GEN3705 command 
successfully executes: ASM3705, TEXT, and EXEC files. 

fnameOO ASB3705 
fnameOI ASM3705 



fnamenn ASM3705 



fnameLO TEXT 
fnameLI TEXT 



fnameLn TEXT 

fname EXEC 

A separate ASM3705 file is created for each assembly job step in the 
Stage 2 input file. Each ASM3705 file created by GEN3705 is given a 
unique filename of the form 'fnamenn'. The first six characters of the 
input filename are concatenated with a two-digit number. For example, 
if the input file is NCP320 TEXT, the output files are NCP32000 ASM3705, 
NCP32001 ASB3705, ..., NCP320nn ASM3705. These files are used as input 
to the 3705 Assembler when it is invoked by the Stage 2 EXEC procedure. 

The GEN3705 program creates several TEXT files. These files contain 
only linkage editor control statements, those statements necessary to 
build the load module file for the 370U/3705 control program. Each of 
the TEXT files created is given a unique filename of the form 'fnameLn'. 
The first six characters of the input filename are concatenated with the 
letter L and a one-digit number. For example, if the input file is 
NCP320 TEXT, the linkage editor output files are NCP320L0 TEXT, NCP320L1 
TEXT, ..., NCP320Ln TEXT. 

The filenames assigned to the linkage editor and assembler files must 
be different. If the filenames were the same, when the ASM3705 files 
are later assembled, TEXT files would be produced which would have file 
identifiers that conflict with the linkage editor files. 
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The EXEC macro file created contains the CMS commands necessary to 
invoke the ASB3705 command for each of the ASM3705 files, and to 
subsequently invoke the linkage editor for each of the Assembler TEXT 
files. If the SAVE option is specified, the EXEC file also contains the 
SAVENCP command which loads the 3704/3705 control program image into 
virtual storage and creates the page-format copy of it on a CP-owned 
volume. The filename of the Stage 2 input file is used as the *ncpname* 
operand for the SAVESCP command. 



SPECIAL CONSIDERATIONS FOR THE STAGE 2 GENERATION PROCEDURE 

Vn/370 recommends that you specify the RON option. When the RUN option 
is specified, GEN3705 stacks a CMS command line to cause the EXEC file 
to execute following the completion of the GEN3705 program. This 
technique minimizes the virtual storage overhead during the EXEC file 
execution. 

If you do not specify the SAVE option, you have to explicitly issue 
the SAVENCP command. If you do specify the SAVE option, be sure that 
the input file has the same filename as the entry reserved in the system 
name table. The system name table is created when a NAHENCP macro is 
issued during a VM/370 system generation. The NAMENCP macro is 
described in "Part 2: Defining Your VM/370 System" and the building of 
the system name table is described in "Part 3: Generating VM/370 (CP, 
CMS, and RSCS) ." 



STEP 8. INVOKE THE EXEC PROCEDURJ CREATED IN STEP 7 

If you specified RUN on the GEN3705 command, this step is executed for 
you. If you did not specify RUN on the GEN3705 command, you must invoke 
the EXEC procedure that the GEN3705 program created. 

The EXEC procedure is given the same filename as the GEN3705 input 
file. It is invoked by entering that filename at the terminal. For 
example, if the input file is NCP320 TEXT, the EXEC file is named NCP320 
EXEC, and can be invoked by issuing: 

NCP320 

at the terminal. 

This EXEC procedure contains CMS commands that: 

• Assemble the 3705 source files (ASM3705 commands) . 

• Build the TXTLIB which the 3705 Assembler needs (TXTLIB commands) . 

• Define all the necessary files; such as, the SYSLIB and SYSLMOD 
files, load libraries, and text libraries (FILEDEF commands) . 

• Link edit the 3705 text files creating a load module (LKED 
commands) . 

You do not have to issue the ASM3705 and LKED commands that create 
the 3704/3705 control program load module; the EXEC procedure does that 
for you. The ASM3705 command is described in Step 6. The FILEDEF and 
TXTLIB commands are described in the VM/370: Command Language Guide for 
General Users. 
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THE LKED COMMAND 



Use the CMS LKED command to create the 3704/3705 control program load 
module from the 3705 Assembler object files. The format cf the LKED 
command is: 




f name 



[ (options. . .[) ] ] 



Cetions: 

[NCAL] [LET] [ALIGN2] [ NE ] [ OL ] [RENT] 

[REUS] [REFR] [OVLY] [XCAL] 

[NAME membername] [LIEE libraryname] 

r 1 r T r t 

IXREFI ITERM | | PRINT | 

I MAP I INOTERM | I DISK | 

lilSTI «- J INOPRINTI 

L J L J 



w h er e : 
f name 



specifies the filename of the object file to be processed. 
The file must have a filetype of TEXT and fixed-length, 
80-character records. 



Opt ions : 

If duplicate or conflicting linkage editor options are specified, the 
resolution is performed by the linkage editor in accordance with its 
normal procedures. If duplicate or conflicting CMS-related options 
are specified, the last one entered on the command line is in 
effect. The CMS-related options are: TERM, NOTERM, PRINT, DISK, 
NCPRINT, NAME, and LIBE. 



NCAL 



LET 



ALIGN2 



NE 

OL 

RENT 
REUS 
REFR 



suppresses the automatic library call function of the 
linkage editor. 

suppresses marking of the load module "not executable" in 
the event of some linkage editor error condition. 

indicates that boundary alignment specified in the 
linkage editor input file is to be performed on the basis 
of 2048-byte boundaries. If this option is omitted, 
alignment is performed on the basis of 4096-byte 
boundaries. 

marks the load module output as "not to be edited" such 
that it cannot be processed again by the linkage editor. 

marks the load module output "only loadable". 

marks the load module reenterable. 

marks the load module reuseable. 

marks the load module refreshable. 
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OVLY processes an overlay structure. 

XCAL allows valid exclusive CALLs in the overlay structure. 

NAME membername 

is the member name to be used for the load module 
created. The member name specified here overrides the 
default name, but it cannot override a name specified via 
the linkage editor NAME control statement. 

LIBE libraryname 

is the filenaiie of a LGADLI5 file where the output load 
module is to be placed. The LOADLIB file specified here 
may also be used for auxiliary input to the linkage 
editor via the INCLUDE statement. 

XREF produces an external symbol cross reference for the 
modules being processed. 

MAP produces only a module map for the processed module (s) . 

iJST includes only linkage editor control messages in the 
printed output file. 

TEEM displays any linkage editor diagnostic messages at the 
user terminal. 

NCTERM suppresses the displaying of diagnostic messages. 

PRINT spools the linkage editor printed output file to the 
printer. 

DISK stores the linkage editor output in a CMS disk file with 
a filetype of LKEDIT. 

NOPRINT produces no output file. 



IiillJS55e l^lioi Control Statements 

Only a subset of the possible linkage editor control statements are 
meaningful in CMS. Since the CMS interface program is not able to 
examine the input data for the LKED command, all of the control 
statements are allowed, even though several of them result in the 
creation of a load module file which cannot be used under CMS. For both 
command options and control statements, see the publication OS^VS 
liiiiJ^SS^ Editor and Loader. 



lii^s Created by the LKED Command 

Tem£orary Workfile: The LKED command produces one temporary file: 

fname SYSUT1 

This file is temporarily created for each link-edit step; any existing 
file with the same file identifier is erased at the beginning of the 
link edit. This file is placed on the read/write disk with the most 
available space. Work space is automatically allocated as needed during 
the link edit and returned to available status when the link edit is 
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complete. Insufficient space causes abnormal termination of the link 
edit. 

Permanent Files ; The LKED command produces two permanent files: 

fname LCADLIB 
fname LKEDIT 

The 'fname LCADLIB' file contains the load module (s) created by the 
linkage editor. This file is in CMS simulated partitioned data set 
format, as created by the CMS OS data management macros. The filename 
of the input file becomes the filename of the LCADLIB file, unless the 
LIBE option is specified. The filename of the input file also becomes 
the member name of the output load module, unless either the NAME option 
or a NAME control statement is used. One or more load modules may be 
created during a single LKED command execution if the NAME linkage 
editor control statement is used in the input file. ihen the NAME 
control statement is used, that name becomes the member name in the 
LOADLIB file. The replace option of the NAME statement determines 
whether existing members with the same name are replaced or retained. 

The 'fname LKEDIT' file contains the printed output listing produced 
according to the XREF, MAP, or LIST options. This file is created on 
disk unless the PRINT or NOPRINT option is specified. The LOADLIB and 
LKEDIT files are placed on (1) the disk from which the input file was 
read, (2) the parent disk, or (3) the primary disk. Failure to obtain 
sufficient space for these files results in abnormal termination of the 
linkage editor. 



STEP 9. SAVE THE 3704/3705 CONTROL PROGRAM IMAGE ON DISK 

If you specified SAVE on the GEN3705 command, this step is executed for 
you. If you did not specify SAVE on the GEN3705 command, you must issue 
the SAVENCP command yourself. 

Note: The VM/370 command privilege class A, B, or C is required to use 
the SAVENCP command. 



THE SAVENCP COMMAND 

Use the CMS SAVENCP command to read a 3704/3705 control program load 
module created by the LKED command, and to load it into virtual storage 
in the CMS user area. Once the load is performed, SAVENCP scans the 
control program image and extracts the control information required by 
CP. The control information is accumulated in one or more 4096-byte 
pages in the CMS user area. When all of the necessary control 
information is extracted, SAVENCP builds the Communications Controllers 
Parameter List (CCPARM) and issues the DIAGNOSE X'50' instruction to 
create the page-format copy of the control program on a CP-owned volume. 
The format of the SAVENCP command is: 
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fname [ (options.. [)]] 

0£ t i on s : 

r T r T r t 

lENTRY symboll |NAME ncpnamel | LIBE libraryname| 

ICXFISIT I I fname 1 llsajne | 

L J L J L J 



where: 



fname 



is the filename of the LOADLIB file where the 3704/3705 
control program load module resides; unless LIBE is specified, 
in which case, it specifies the member name of the image 
within the LOADLIB. This name is used as the ncpname for the 
DIAGNOSE instruction, unless the MAME option is also 
specified. 

Options 

EMTRY symbol 

is the external symbol of the entry point in the 3704/3705 
control program load module. The default, CXFINIT, is the 
entry point of the standard NCP or PEP control programs. (The 
standard entry for the Emulation Program is CYASTART.) If the 
SAVE option of the GEN3705 command is specified, this symbol 
is set in the output EXEC file according to the Stage 2 input 
file. 

NAME ncpname 

is the ncpname to be used when the DIAGNOSE parameter list is 
built. The ncpname specified must match an entry in the 
system name table. These entries are created with the NAMENCP 
macro when VM/370 is generated. 

LIBE libraryname 

is the filename of a load module library file, filetype 
LOADLIB, which contains the control program image as member 
' fname* . 



EXECUTION OF THE SAVENCP PROGRAM 

The DIAGNOSE X'50' instruction invokes the CP module DHKSNC to: 

• Interpret the parameter list (CCPARM) built by SAVENCP. 

• Check the parameter specifications against the NAMENCP macro for the 
3704/3705 control program. 



Write the page-format image of 
appropriate CP-owned volume. 



the control program onto the 



The parameter list for the DIAGNOSE instruction must start on a 
4096-byte boundary. 

When the DIAGNOSE X«50' instruction is executed, the module DMKSNC 
searches the DMKSNT module for a NAMENCP macro of the same ncpname as 
the one in the CCPARM parameter list. The values specified in the 
parameter list are compared to those specified in the NAMENCP macro. If 
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any parameters conflict, an error message is displayed at the terminal. 
If no error conditions are detected, DMKSNC starts to transfer the 
control program image from CMS virtual storage to the CP-owned volume 
specified in the MAMENCP macro. Successful completion of this process 
completes the generation of a 3704/3705 control program for VM/370 use. 



STEP JO. LOAD THE 370U/3705 CONTROL PROGRAM 

The 3704/3705 control program is automatically loaded each time the 
VM/370 system is loaded, if the CPNAME operand was specified on the 
RDEVICE macro when VM/370 was generated and if the 3704/3705 is online. 
If the CPNAME operand was not coded, you must issue the CP NETWORK LOAD 
command line to load a 3704/3705 control program into the 3704/3705 
Communications Controllers' storage. 



THE NETWORK LOAD COMMAND LINE 

Use the NETWORK LOAD command to initiate the loading of an NCP, PEP, or 
EP control program into a 3704/3705 Communications Controller. The 
format of the NETWORK LOAD command line is: 



I NETwork | LOAD raddr ncpname I 

I I 



w h er e : 

LOAD initiates the control program load operation. 

raddr is the real address of the 3704/3705 to be loaded. 

ncpname is the name, defined by a NAMENCP macro, of the 3704/3705 
control program image to be loaded into the 3704/3705 
specified by raddr. 

EXECUTION OF THE NETWORK LOAD COMMAND 

The NETWORK LOAD command accesses the control program image using the 
information in the system name table (DMKSNT) entry created by the 
NAMENCP macro. If the 3704/3705 specified in the command is not in an 
"IPL Required" state at the time the command is issued, the message: 

DMKNET461R CTLR raddr IPL NOT REQUIRED; ENTER "YES" TO CONTINUE: 

appears at the terminal. If the reply to the message is other than 
"yes", the command terminates without loading the 3704/3705. Otherwise, 
the loader bootstrap routines are written to the 3704/3705 and loading 
starts, VM/370 does not execute the "bring-up" test routines as a part 
of the load process. If these tests are to be made, they must be run 
from a virtual machine with the 3704/3705 dedicated. 

When the load of the control program image is complete, the command 
processor verifies that the 3704/3705 configuration described by the 
control program can be serviced by the VM/370 CP control blocks in 

262 VM/370: Planning S System Generation Guide 



storage. In the case of CPTYPE=NCP (or PEP) , this involves creating (or 
refreshing) the control list associated with the 370U/3705 real device 
block (RDEVBLCK). The information necessary to do this is contained in 
the system pages at the beginning of the control program image on 
secondary storage. 



SPECIAL CONSIDERATIONS FOR LOADING THE EP 3704/3705 CONTROL PROGRAM 

If a 3704/3705 Emulation Program is automatically reloaded after a 
3704/3705 failure, the system may loop after the restart. The message 

DMKRNH463I CTLR raddr UNIT CHECK; RESTART IN PROGRESS 

and two responses 

CTLR raddr DUMP COMPLETE 

CTLR raddr ncpname LOAD COMPLETE 

indicate that the 3704/3705 has been reloaded. If the system loops 
after the second response, you must reset all emulator lines from the 
3704/3705 control panel. 

If the automatic dump feature is not enabled, one of the messages 

DMKRNH462I CTLR raddr UNIT CHECK; IPL REQUIRED 

— or — 

DMKRNH464I CTLR 'raddr' CC=3; DEPRESS 370X "LOAD" BUTTON 

indicates a 3704/3705 abnormal termination. The 3704/37C5 Emulation 
Program must be reloaded via the NETWORK LOAD command. If the system 
loops when an attempt is made to enable the lines, you must reset all 
emulator lines from the 3704/3705 control panel. 

The IBM 3704 and 3705 Communications Controllers O£eratorj[_s Guide 
describes the procedure for resetting emulator lines from the 3704/3705 
control panel in its "Generating Channel End/Device End with Emulator 
Program" section. 



SPECIAL CONSIDERATIONS FOR LOADING THE NCP AND PEP 3704/3705 CONTROL 
PROGRAMS 

Special care must be taken when loading a Network Control Program or 
Partitioned Emulation Program. The NETWORK LOAD command should not be 
used to load either an NCP or PEP except at VM/370 system IPL time, 
unless that same 3704/3705 control program was active just prior to the 
load (that is, unless it is reloaded immediately). A VM/370 system 
abnormal termination (code PTR007) may result if the 3704/3705 is 
loaded, for the first time, during normal operation with an NCP or PEP 
program. However, if an NCP or PEP 3704/3705 control program must be 
loaded during system operation, all resources must first be freed. 

If there are active resources, the resources must be disabled and the 
NETWORK SHUTDOWN command must be issued before the operator can 
successfully issue the NETWORK LOAD command. 
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STEP 11.. LOGGIHG OH THROUGH THE 3704/3705 

Because a 3701/3705 can support emulator-aode lines, NCP-aode lines, and 
lines that can be varied to either mode, and can also support a variety 
of terminals, the procedure for logging on is sometimes complicated. 
Use the following procedure to log on to VM/370. 



TURN THE POWER ON 



First, turn the power on for your terminal and wait 15 to 30 seconds. 



CHECK FOR AN ONLINE MESSAGE 

Second, look for an online message at your terminal. 

If one of the following messages appears at your terminal 

vm/370 online xxxxxx xxxxxx 

— or -- 

xxxxxx xxxxxx vm/370 online 

I your terminal is a 27U1 connected to VM/370 via a 2701/2702/2703 line or 
via a 3701/3705 line in emulation mode. You can proceed with the normal 
logon procedure for your type of terminal, as described in the VM/370: 
Terminal User2.s Guide. 

If the messsage 

vm/370 online 

I appears at your terminal, your terminal is: 

I • A 2741 connected to VM/370 via a 370U/3705 line in NCP mode, without 
I the Multiple Terminal Access feature, or 

I • A 1050 or CPT-TWX Model 33/35 terminal connected to VM/370 in EP 
I mode. 

You can proceed with the normal logon procedure for your terminal type. 
This procedure is described in the VM/370: Terminal User2.s Guide. 

If you receive a message at your terminal in the form 

xxxxxx xxxxxx 

where the x's indicate that the message is unintelligible, your terminal 
is most likely connected to a 3704/3705 line in NCP mode that is defined 
for a different terminal type. For example, you may have an EBCD 
terminal on a line defined for Correspondence terminals. Use the 3 (at 
sign) character to determine what kind of terminal you are using. If 
the a character is an uppercase 2, your terminal is a Correspondence 
2741; otherwise, it is an EBCD 2741. 
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If a 2741 terminal is connected to VM/370 via a 3704/3705 line in NCP 
mode, you must press the Return key before the "vm/370 online" message 
appears at the terminal. If a terminal is connected to VM/370 via a 
370U/3705 line in NCP mode, and has the Multiple Terminal Access (MTA) 
feature, then the "vm/370 online" message does not appear at the 
terminal and, after approximately 15 seconds, the terminal locks and 
unlocks. You must perform a special sign-on procedure before continuing 
with the normal logon procedure. 

The sign-on procedures for the terminals supported for use with the 
3704/3705 under the control of VM/370 are summarized in the following 
paragraphs. If you have any further difficulties accessing VM/370 
through a 3704/3705, see the VM/37 0: Terminal User^s Guide and the 3704 
§11^ 3705 Generati on and Utilities Guide for complete descriptions of the 
procedures summarized here. 



FOLLOW THE SPECIAL SIGN-ON PROCEDURES FOR 3704/3705 LINES THAT ARE IN 
NCP MODE AND ALSO HAVE THE MTA FEATURE 

Three sign-on procedures are described: the 2741, 1050, and CPT-THX for 
terminals on lines with the MTA feature. Once the sign-on procedure is 
completed, the message 

vm/370 online 

should appear at your terminal. You can then proceed with the normal 
logon procedure described in the VM/370: Terminal UserJJ^s Guide. 

MTA Sign-on Procedures for IBM 2742 Terminal 

1. Dial the telephone number of the MTA line to be used for 
communicating with the controller. 

2. When the keyboard unlocks, enter /". 

3* Press the Return ke'". 

If the "vm/370 online" message appears at your terminal, you have signed 
on successfully and may proceed with the normal logon. If no message 
appears at your terminal but your terminal unlocks, press the Return key 
in an attempt to get the "vm/370 online" message. However, if the type 
element moves back and forth, the sign-on is unsuccessful; you must 
repeat steps 2 and 3 of the sign-on procedure. 

I Note: The 3767 terminal (operating as a 2741) is not supported by NCP 
I lines with the MTA feature because of the 300 bits/second line speed. 



HI A Sian-on Procedure for IBM 1050 Terminal 

1. Dial the telephone number of the MTA line to be used for 
communicating with the controller. 

2. When the Proceed light comes on, enter /" . 

3. Press the Return key. 

4. Enter BOB. 
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If the "vin/370 online" message appears at your terminal, you have signed 
on successfully and may proceed with the normal logon. If no message 
appears at your terminal but your terminal unlocks, press the Return key 
in an attempt to get the "vm/370 online" message. However, if the type 
element moves back and forth, the sign-on is unsuccessful; you must 
repeat steps 2, 3, and 4 of the sign-on procedure. 



MTA Sian-on Procedure for CPT-THX Terminal 

1. Dial the telephone number of the MTA line to be used for 
communicating with the controller. 

2. Press the WRU (Where Are You) key within three seconds after the 
audible data tone begins. 

If the typing mechanism does not "jump" within a few seconds, you have 
signed on successfully and may proceed with the normal logon. If the 
typing mechanism does "jump," the sign-on is unsuccessful; press the WRU 
key again or repeat both steps of the sign-on procedure. 



LOGGING ON AFTER AN NCP CONTROL PROGRAM HAS ABNORMALLY TERMINATED 

If an NCP 3704/3705 control program (with the automatic dump and reload 
options previously set) abnormally terminates but VM/370 continues to 
run, VM/370: 

1. Disconnects all the 3704/3705 users 

2. Dumps the contents of 3704/3705 storage 

3. Reloads the 3704/3705 control program 

4. Enables the lines again 

At this point, each user must log on again. Any user that does not log 
on with 15 minutes is logged off the system. 

STEP 12. APPLYING PTPS TO THE 3704/3705 LOAD LIBRARY 

If necessary, it is possible to apply Program Temporary Fixes (PTFs) 
directly to the 3704/3705 load library. The CMS ZAP program applies the 
PTF. See the "ZAP Service Program and How to Use It" section of Part 
6. 
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Testing the 3704/3705 Control Program 



After you have generated a 370U/3705 control program, loaded it, and 
logged on, you may want to test the 3704/3705 control program. Several 
CP commands are provided to control the operation, check the status, and 
dump the contents of the 3704/3705. The NETHORK command loads and dumps 
any 3704/3705 control program. It also controls the operation of NCP 
and FEP 3704/3705 control programs, while the existing CP commands 
(ENABLE, DISABLE, QUERY, DISPLAY, VARY, and HALT) provide similar 
support for EP 3704/3705 control programs. The NCPDUMP command formats 
and prints a dump of 3704/3705 storage. Use these commands to test the 
3704/3705 control program. 

The NETWORK, ENABLE, DISABLE, QUERY, DISPLAY, VARY, and HALT commands 
are described in the VM/370: OBeratorJ.s Guide and the VMZ370: Command 
Iii^Ha^age Guide for General Users . 



NCPDUMP SERVICE PROGRAM AND HOW TO USE IT 

NCPDUMP is a CMS command. It processes CP spool reader files created by 
3705 dumping operations, that is, dump files that are produced as a 
result of the CP NETWORK command specified with the DUMP operand and 
either automatic or immediate mode. 

The NCPDUMP file processing operation can include: 

• Erasing a specific CMS NCPDUMP file after printing it 

• Formatting the dump 

• Printing the dump 

• Assigning an identifier to the CMS NCPDUMP file 

• Creating the CMS NCPDUMP file from the spool file 

Although NCPDUMP is a CMS command, its use is restricted to the user 
identified by the SYSDUMP operand of the SYSOPER macro in DMKSYS during 
VM/370 system generation. The operation of NCPDUMP is similar to 
VMFDUMP operations. A general description of the NCPDUMP operation 
follows the command description. 

The NCPDUMP command has the following format: 



I NCPDUMP I [DUMPxx] [ ([ERASE ][NOFORM][ MNEMONIC ][) ]] | 

.J 



where : 

DUMPxx is the filename of a CMS file containing a 3704/3705 
Communications Controller program dump. This dump was created 
by a previously invoked NCPDUMP command with the ERASE operand 
not specified. 

ERASE erases the current CP DUMP file or a specified DUMPxx 
(filename), saved CMS file. 

NOFORM specifies that a formatted control block is not desired. 
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MSEMONIC includes 3705 Assembler ■nenonic operation codes in the 
printed output. 

The HETHCRK command invoked with the DDMPxx operand, as stated 
previously, produces CP files that contain the contents of a designated 
370U/3705 Communications Controller unit buffer. These CP files reside 
as a spooled reader input assigned to a system-designated user. The CMS 
HCPDUBP command invoked by this user formats (if requested) and prints 
the contents of these files. 

The NCPDUHE program creates a CMS file with a filename DOMPxx and a 
filetype of NCPDUMP, and erases the original spooled HETMORK initated 
dump reader file. The created CMS file is erased if you specify ERASE, 
otherwise it is kept. 

A maximum of ten dumped spooled files can be processed and saved, and 
later recalled, if necessary, by the system assignment of an xx 
identifier suffix to the CMS DUMPxx filename. The "xx" is a decimal 
number from 00 to 09, depending on any existing files of a similar name. 
For example, if the files DUMPOO NCPDUMP and DUMP01 NCPDUMP already 
exist, the new file would be called DUMP02 NCPDUMP. The file thus 
created is retained for later use unless the ERASE option is specified, 
in which case the file is erased immediately after the dump is printed. 
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Part 5: The Standalone Spool Remote Program 



Part 5 describes the procedure for installing the standalone spool 
remote program (DMKSRP) for the IBM 2780. It contains an introduction to 
the 2780 and information about: 

• Installing the DMKSRP program 

• Testing 2780 operation 
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Introduction to IBM 2780 Data Transmission Terminal 



The standalone spool remote program (DMKSRP) transfers data between a 
VM/370 spool file and a 2780. Printer files are sent in ncntransparent 
mode. To increase throughput, VM/370 removes all trailing blanks from 
each print line before sending them. Printed output may be stopped at 
any <.j.me to senu a ccntrcj. card to the system (wut punched output may be 
stopped for this purpose only if the 2780 is in Allow Punch Interrupt 
[API] mode). See the 0/370 iQEeratorj.s Guide for a description of API 
mode. 



IBM 2780 DATA TRANSMISSION TERMINAL CHARACTERISTICS 

The IBM 2780 Data Transmission Terminal (Model 2) can be used as a 
remote spooling work station under VM/370. It provides medium-speed 
input and output capabilities over common carrier communications 
facilities. The 2780 Model 2 is used for card input, printed output, 
and punched output. 

The "Configurations" section of Part 1 lists the 2780 features that 
the VM/370 standalone spool remote program requires. 
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Installing DMKSRP 



When you initially install the DMKSRP prograi, or make changes to it, 
you must code and assemble the SBP2780 macro. The text file produced by 
the assembly is placed on your A-disk. 

To install the DMKSRP program, you must: 

• Format your A-disk. 

• Code the SRP2780 macro. 

• Assemble the DMKSRP program. 

The following procedure describes the installation process. 

STEP 1. FORMAT YOUR A-DISK 



Log on VM/370, IPL a CMS virtual machine and format your A-disk. 
the CMS FORMAT command to format your A-disk. 



Use 



STEP 2. CREATE A DMKSRP ASSEMBLE FILE 



Use the CMS Editor to create a file called DMKSRP ASSEMBLE. The file 
must contain the SRP2780 macro and an END statement. The END statement 
must specify DMKSRP80 as the entry point. 

The format of the SRP2780 macro is: 



Name 



label 



Operation 



SRP2780 



Operands 



r 1 

|IPLUNIT=cuu, I 
I lEiU NIT= OC , I 

L J 

r 1 

I REMUNIT=cuu,| 

IREMUNIIfOlir I 

L J 

r T 

|CONUNIT=CUU| 
I CO NU NITf 9 I 

L J 



r T r T 

|PDNUNIT=cuu, I |PRTONIT=CUU,| 

I £21 DMI If op , I I P RT D NI Tf OE , | 

L J L "* "" J 



r 1 

I PRTRDR=CUU, I 
I PRT R D Rf 10 , I 

L J 



r n 

|PUNRDR=CUU, I 

IPUNRERzPJJrl 

L ~ J 



where : 

label 

is any assembler language label. 

IPLUliIT=cuu 

is the virtual address (cuu) of the device that loads the DMKSRP 
program. The default value is X'OOC. 
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PUHUSIT=cuu 

is the virtual device address (cuu) of the virtual unit record 
device that DMKSBP uses for punching to a real card punch and for 
sending remote card files to other users. The real card punch can 
be set at the central computing location or at a remote location. 
The default value is X'OOD*. 

PRTOIJIT=cuu 

is the virtual address (cuu) of the virtual unit record device that 
the DBKSHP program uses for printing to the real printer at the 



r-on+-T-a1 ^r»iBr>n+ -I n n 1n^a4*T/^n TKia #1o-PaiiT+ -wa 1 



11 «» 1 



REMUliIT=cuu 

is the virtual address (cuu) of the binary synchronous 
communications line attached to the 2780 work station. The default 
value is X«018». 

PRTRDR=cuu 

is the virtual address (cuu) of the virtual reader containing print 
files for the 2780 work station. The default value is X'010'. 

PDIlRDR=cuu 

is the virtual address (cuu) of the virtual reader containing punch 
files for the 2780 work station. The default value is X'011'. 

CONDNIT=cuu 

is the virtual address (cuu) of the console used to communicate 
with the DMKSRP program. The default value is X'009'. 

Note: You can specify the same virtual address for PRTRDR and PUNRDR. 

An example of a DMKSRP ASSEMBLE file is: 

SRP TITLE 'DMKSRP VERSION v, LEVEL 1,,.' 

RJE2780 SRP2780 IPLUNIT=OOC, PDNUNIT=00D,PRTONIT=OOE, X 

REMUNIT=018,PRTRDR=010, X 

PUHRDR=011 ,CONDNIT=009 
END DMKSRP80 



STEP 3. USE VMFASM TO ASSEMBLE DMKSRP 

Issue the VMFASM command to assemble DMKSRP and apply any updates that 
exist. For example, 

VMFASM DMKSRP DMKR20 

VMFASM places the text deck it creates on your A-disk, VMFASM is 
described in "Part 6: Updating VM/370," 



STEP i». LOG ON THE 2780 VIRTUAL MACHINE 

If you are installing the 2780 spool remote program, your VM/370 
directory should have an entry for a virtual machine to execute the 
2780. The VM/370 Directory program control statements that are 
distributed with the starter system have an entry for a 2780 virtual 
machine. Refer to Part 2 to see that entry. The following VM/370 
directory is representative of a 2780 virtual machine. 
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USER BEB2780 REMOTE 320K 

ACCOUNT number 

CONSOLE 009 3210 

SPOOL OOE 1403 A 

SPOOL OOD PUNCH A 

SPOOL OOC 2540 READER A 

SPOOL 010 2540 READER A 

SPOOL Oil 2540 READER A 

OPTION REALTIMER 

MDISK 191 3330 003 001 CPVlLO H 

LINK CPSYS 190 190 R 

LINK CPSYS 194 194 R 

DEDICATE 018 018 

The DEDICATE control statement defines a transmission control unit with 
a binary synchronous communication (ESC) line that connects the 2780 to 
this virtual machine (REM2780) . If you do not include the DEDICATE 
statement in the directory entry, the user of the 2780 virtual machine 
must explicitly request that the real BSC line be attached to his 2780 
virtual machine when he logs on. The REALTIMER option is required for 
the DMKSRP program error recovery procedures. 



STEP 5. PUNCH THE DMKSRP TEXT FILE 

Make the text deck created in Step 3 available to your virtual machine 
as an input spool file. Issue the following CMS commands: 

spool pch to * cont 

punch 3card loader (noheader) 

punch dmksrp text (noheader) 

spool punch nocont 

close pch 



STEP 6. LOAD THE DMKSRP PROGRAM 

You can then IPL the DMKSRP program by entering CP mode and issuing the 
IPL command, as follows: 

ipl 00c 

OOC is the address of the virtual card reader that contains the text 
file punched in Step 5. 



STEP 7. ENIBLJ THE LINE 

When the 2780 virtual machine is initialized, the message ENABLING is 
displayed at the terminal. At this time, you can disconnect your 
terminal and make the remote terminal available to another user. 

If your 2780 is on a point-to-point line, the connection between the 
2780 and the central computer is established when the enable is 
performed. If your 2780 is on a switched line, you must determine which 
work station is to be called, make sure the data set at that work 
station is in auto answer mode, and then call the station to establish 
the line connection. 
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Note: You can perform Steps 5, 6, and 7 ty invoking a CMS EXEC 
procedure, such as: 

&CONTROL OFF 

CP CLOSE PCH 

CP SPOOL PCH TO * CONT CLASS Q 

PUNCH 3CABD LCAEER (NOHEADEB) 

PUNCH DMKSRP TEXT (NOHEADER) 

CP SPOOL PUNCH NOCONT 

CP CLOSE PCH 

CP SPOOL PCH OFF CLASS A 

CP SPOOL OOC CLASS Q 

CP DISCCNN 

CP IPL OOC CLEAR 

If you use the preceding EXEC procedure, you should change OOC to the 
address you specified for IPLUNIT on the SRP2780 macro. Use a spooling 
class in the third and ninth lines that allows the DMKSRP program to be 
loaded whether or not there are other spool files in the virtual 
reader. The class letter Q has no special significance in this example; 
you should use a spooling class that is not normally used by your 
installation. (The file 3CARD LOADER is found on the VM/370 system 
update disk, along with the DMKxxx ASSEMBLE files.) 

If this EXEC procedure is used, the ENABLING message does not appear 
at your terminal because your virtual machine is disconnected before 
DMKSRP is loaded. 



CONTROLLING 2780 OPERATION 

Once a connection is established between the 2780 and the VM/370 system, 
control is retained or changed through a set of DMKSRP control cards. 
The 2780 operator creates these cards and puts them in the 2780 cards 
reader. These control cards are described in the VM/37C: O£eratorj|.s 
Guide. 



TESTING 2780 OPERATION 

You can verify that the DMKSRP program is operating correctly by 
performing the following tests from another virtual machine (not the 
2780 's virtual machine) that has access to CMS disk files: 

SPOOL D TO REM2780 
SPOOL E TO REM2780 

where REM2780 is the userid of the virtual machine executing the 2780 
spool remote program. Then issue both of the following commands: 

PRINT fname ftype 
PUNCH fname ftype 

At the 2780, have a CONTINUE control card and an ID control card 
prepared, specifying on the ID card the VM/370 userid of the testing 
virtual machine. Place the CONTINUE card in the 2780 reader hopper. 
Ready the printer, press the reader end-of-file pushbutton, and press 
the reader START pushbutton twice. Printing should begin at the 2780. 

When the TERM ADR light comes on and the alarm sounds, rotate the 
MODE switch to reset the 2780, Place a CONTINUE control card, followed 
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by blank cards, in the hopper and ready the 2780. Punching should 
begin. 

When the 2780 activity stops, remove the remaining blank cards from 
the reader hopper and place the ID card, followed by the deck that was 
punched at the 2780, in the reader hopper. Be sure to remove the blank 
cards preceding and following the data cards that were punched. Once 
again, ready the printer, press the reader end-of-file pushbutton and 
press the reader START pushbutton twice. The card deck should be read 
at the 2780 and transferred to the testing virtual machine, which should 
then issue the command: 

HEADCARD fname ftype 

to read the card deck and make it a CMS file. Compare the original file 
and the file which was read back to verify the correct operation of the 
2780 spool remote program. 

Under normal operation, the 2780 printer is ready, with the rotary 
switch on the reader/punch set on transmit transparency. Then printed 
spooled output can be received, and control cards can be sent through 
the reader. If the terminal address (TERM ADR) light comes on and the 
audible alarm sounds, the DMKSRP program is attempting to punch spooled 
output. Perform a nonprocess runout to clear the punch. Rotate the MODE 
switch to reset the 2780. Place a COHTINUE control card, followed by 
blank cards, in the hopper. Press the START key on the reader/punch. 
The 2780 should begin to punch the spooled output. 



276 VM/370: Planning & System Generation Guide 



Part 6: Updating VM/370 



I Part 6 tells you how to apply Prograi Temporary Fixes (PTFs) and updates 

I to an installed VM/370 system. It contains information about the 

I following: 

I • Supporting a VM/370 System 

I • Updating Modules Using the VMFASM EXEC Procedure 

I • using the VMFMAC EXEC Procedure to Update Macro Libraries 

I • Using VMFLOAD to Generate a New Nucleus 

I • The Loader 

I • Using the GENEHATE EXEC Procedure to Generate a New CP or 

I CMS Nucleus 

I • Using the VMFBLD EXEC Procedure to Build a New Nucleus 

} * Using the CnSGEND EXEC Procedure to Generate a CMS Module 

I • Using the ASMGEND EXEC Procedure to Generate the Assembler 

I • Recommended Procedures for Updating VM/370 
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Supporting a VM/370 System 



The multiple virtual machine environment created by VM/370 permits 
support of toth hardware and software to be done concurrently with other 
installation work. 

Virtual machines can be used to: 

• Generate and test new systems 

• Apply and test PTFs 

• Run hardware diagnostics 

• Retrieve and examine VM/370 ABEND dumps and error recordings 

• Examine portions of real VM/370 storage 

• Trace the execution of a system in a virtual machine 

Before installing VM/370, you should develop an account support plan 
with the IBM FE program systems representative. Appropriately 
configured virtual machine entries should be included in the VM/370 
directory for the service representative. Two virtual machines, with 
userids CE and MAINT, are defined for these representatives in the 
VM/370 directory distributed with the starter system. 



XHZHO UPDATE PROCEDURES 

Using the VM/370 update facility, you can update files with several 
levels of updates and/or any number of Program Temporary Fixes (PTFs) . 
Procedures are supplied for assembling the updated source code to 
produce a uniguely identifiable text file. The file has a unigue 
filename and records that identify the origin of the updates, macro 
libraries, and source statements. 

Procedures are provided for generating load files from various object 
modules, and for generating MACLIB files from various COPY and MACRO 

J. J. J. CO . 

The update structure involves a file naming convention for update and 
text files, a set of programs to support the processing, and a set of 
BXEC procedures to process the files. 

The update procedures and programs supplied with VM/370 are: 

VMFASM Incorporates PTFs and/or updates and creates a new 

text file 

VMFLOAD Generates a new CP, CMS, or RSCS module 

CMSGEND Generates a new CMS module 

GENERATE Generates a new VM/370 system 

GENERATE IPIDECK Generates a new standalone version of a service 

program on disk 

GENERATE SRVCPGM Punches the service programs on cards 

VMFMAC Generates a new CMS or CP macro library 

CMS UPDATE Command Updates modules 
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All modules prefaced by the letters DMK are CE modules. There are two 
kinds of CP modules: those that are part of the CP nucleus (these 
modules are contained in the CPLOAD EXEC file) and those that are not 
part of the CP nucleus (service programs that execute either standalone 
or under CMS) . The programs that execute standalone are DMKDDP, DMKDIR, 
and DMKFMT. If you apply a PTF to these modules and create a new text 
deck, use the GENERATE EXEC to create a new standalone file. 

I The service programs that execute under CMS are: 

I • DASD Dump Restore Program (module DMKDDR) 

I • Directory program (module DMKEIR) 

I • VMFDUMP, the virtual dump program (module DMKEDM) 

I • NCPDUMP, the 3704/3705 dump program (module DMKRND) . 

If you apply updates to these modules, use the CMSGEUD EXEC to create a 

new CMS module. The module name to specify is DDR, DIRECT, NCPDUMP, or 
I VMFDUMP, respectively. CMS cannot execute the Format/Allocate program 
I (module DMKFMT) and the IBCDASDI Virtual Disk Initialization program 
I (module IBCDASDI). If you apply a PTF to any DMK module other than 

these six service programs, you must reload CP (using the VMFLOAD 

command) . 



UPDATING A MODULE 

The following discussions assume that areas containing the source code 
for CP and CMS are added to the appropriate virtual machine 
configurations. Source code for the CMS system is included on the CMS2 
tape; source code for CP is included on the CP2 tape. These tapes are 
distributed by the Program Information Department (PID) . 

VM/370 has update procedures to incorporate changes (additions, 
deletions, or corrections) into an existing module, macro, or copy file. 
For example, if you apply updates to the DMKVAT module, the VMFASM 
update procedure: 

• Locates the DMKVAT source file. It is the unmodified Assembler 
Language source code that is distributed with the VM/370 system. 

• Locates the update control file for DMKVAT. The control file name is 
specified on the VMFASM command. The control file can have any 
filename, but must have a filetype of CNTRL. It contains records 
indicating how to apply the updates. 

• Applies the updates to the specified source (in this case, DMKVAT) 
and gives the updated source a temporary name by concatenating a $ 
(dollar sign) to the first seven characters of the filename (in this 

case, the temporary filename is $DMKVAT) . 

• Puts macro library names specified in the control file into the 
proper Assembler library list. (The macro libraries reguired at 
assembly time are specified in a MACS record in the control file.) 

• Assembles the updated source file ($DMKVAT) and creates an updated 
object deck. The object deck filetype is derived from information 
found in the control file. The filename of the updated object file is 
the same as that of the original source, DMKVAT. 

As the VMFASM update procedure progresses from one step to the next, 
informational or error messages are displayed. To more fully understand 
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how the update procedures operate, you need to know what a control file 
contains, and how it is handled. The following discussion provides this 
information. 



COHTROL FILES 

I Control files are used by the CMS UPDATE coimand and by the VMFASM EXEC 
! procedure* You may have one or more control files to specifv various 
combinations of updates and macro libraries to be used at different 
times. A control file contains the following types of records: 

• The MACS Record. This record contains the names of macro libraries to 
be used at assembly time. A MACS record is required for a control 
file used by the CMS UPDATE command; it is optional for a control 
file used by the VMFLOAD EXEC procedure. A control file must not 
contain more than one MACS record. If a MACS record is included, it 
must precede any other records except comments. Up to eight libraries 
may be specified in the MACS record (if space petmits) . A MACS record 
has the following format: 

uplevel MACS libl lib2 lib3... 

I The uplevel field is usually TEXT; it is not used to generate the 
I filetype of the updated file. 

• Update identification records. These records identify updates that 
are to be applied to a particular source file, if such a file exists. 
An update identification record has the following format: 

uplevel upid 

where uplevel is an update level identifier that generates a filetype 
for the new file (the new filetype uniquely identifies the updated 
source file). The field, upid, is the update identification; it can 
be from one to four characters long. This update identification is 
concatenated with the prefix UPDT to identify the filetype of the 
direct update to be applied. The filename must be the same as the 
name of the file to be updated. For example, if an update 
identification record for DMKVAT is: 

TEXT NEW1 

the update file is called DMKVAT UPDTNEH1. The update level identifer 
is TEXT. 

• AUX file identification records. These records contain the names of 
auxiliary files (AUX files) , which in turn contain a list of 
filetypes of update files to be applied to a particular source file. 
An auxiliary file identification record has the following format: 

uplevel AUXnnnn 

where uplevel is an update level identifier that generates the 
filetype of the updated source file. The string, nnnn, is an 
identification string that can be from one to four characters long. 
This identification string, with the prefix AUX, is the filetype of 
the auxiliary file that contains the list of updates to be applied. 
The filename of the auxiliary file is the same as the filename of the 
source file to be updated. For example, if an AUX file identification 
record that contains a list of updates for DMKVAT is: 
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TEXT AUXnnnn 

then the auxiliary file called DBKVAT AUXnDDn contains the filetypes 
of the update files that are to be applied. These update files have 
the same filename as the source file to be updated. 

• Comments. An asterisk (*) in the first column of the record 
identifies a comment record. 

Bote: Control file records in the format that was used under VM/370 
Release 1 are still accepted under Release 2. For example, an ADX file 
identification record in the format 

TEXT nnnn ADX 

is still accepted by the update procedures. 

A control file can have any number of update identification records, 
ADX file identification records, and comments, but can have only one 
MACS record. The control file can have any filename. Note, however, 
that VM/370 updates from IBM normally use the following special control 
files: 

• A control file for CP source, copy, and macro updates is called 
DMKR20 CNTRL. 

• A control file for CMS source updates is called DMSR20 CNTRL. 

• A control file for CMS macro and copy updates is called DMSM20 
CNTRL. 

• A control file for assembling the NCPDDMP source is called NCPR20 
CNTRL. 

I • A control file for assembling RSCS source, copy, and macro updates is 
I called DMTR20 CNTRL. 

The DMKR20 CNTRL file contains the following records: 

TEXT MACS DMKMAC CMSLIB OSMACRO 
TEXT AUXR20 

The DMSR20 CNTRL file contains the following records: 

TEXT MACS CMSLIB OSMACRO 
TEXT ADXR20 

The DMSM20 CNTRL file contains the following record: 

COPY ADXM20 

The NCPR20 CNTRL file contains the following records: 

TEXT MACS OSMACRO DMKMAC CMSLIB 
TEXT ADXR20 

I The DMTR20 CNTRL file contains the following records: 

I TEXT MACS DMTLOC DMTMAC 
I TEXT ADXR20 
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APPLJING PTFS TO VM/370 



PTF updates are distributed in card or magnetic tape form, or as APAB 
answers typed on coding forms. In any case, a CnS file (with the correct 
filename and filetype) must be created on a disk to contain the update. 
The disk must belong to the user (userid MAINT) who is responsible for 
updating VK/370. The disk may be the CP or CMS source disk, but it is 
usually a separate disk. 
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OOC 


2540 READER A 




SPOOL 


OOD 


2540 PUNCH A 




SPCCI 


OOE 


1403 A 






MDISK 


190 2314 


035 110 CPV2L0 


MR 


READ 


MDISK 


191 2314 


019 010 CPV2L0 


MR 


READ 


MDISK 


194 2314 


145 058 CPV2L0 


MR 


READ 


MDISK 


199 2314 


034 001 CPV2L0 


HR 


READ 


MDISK 


193 2314 


001 050 USERD1 


MR 


READ 


MDISK 


294 2314 


051 050 USERD1 


MR 


READ 


MDISK 


393 2314 


001 110 USERD2 


MR 


READ 


MDISK 


394 2314 


001 110 0SERD3 


MR 


READ 


MDISK 


390 2314 


101 003 USERD1 


MW 


READ 


MDISK 


cuu 2314 


000 203 yyyyyy 


MW 





where cuu and yyyyyy are the address and label of your system residence 
volume defined in your DMKSYS module. 



A suggested virtual machine configuration for updating a 3330 systei 



is: 



USER MAINT 
ACCOUNT ( 
OPTION 
CONSOLE 
SPOOL 
SPOOL 
SPOOL 
MDISK 
MDISK 
MDISK 
MDISK 
MDISK 
MDISK 
MDISK 
MDISK 
MDISK 
MDISK 



CPCMS 512K 16M BCEG 
installation defined) 
ECMODE REALTIMER 



009 3215 

OOC 2540 READER A 
OOD 2540 PUNCH A 
OOE 1403 A 

190 3330 030 076 CPV2L0 MR READ 

191 3330 016 007 CPV2L0 MR READ 
194 3330 106 044 CPV2L0 MR READ 
199 3330 029 001 CPV2L0 WR READ 
193 3330 001 030 USERD1 MR READ 
294 3330 031 030 USERD1 MR READ 

393 3330 061 060 USERD1 MR READ 

394 3330 121 060 USERD1 MR READ 
390 3330 181 002 USERD1 MW READ 
cuu 3330 000 403 yyyyyy MW 



where cuu and yyyyyy are the address and label of your system residence 
volume defined in your DMKSYS module. 



I is : 



A suggested virtual machine configuration for updating a 3340 system 
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USER MAINT CPCMS 512K 16M BCEG 
iCCOUHT (installation defined) 
OPTION ECBODE REALTIMER 
COMSCLE 009 3215 
SPOOL OOC 2540 READER A 
SPOOL OOD 2540 POHCH A 
SPOOL OOE 1403 A 
BDISK 190 3340 030 076 CPV2L0 MR READ 
MDISK 191 3340 016 007 CPV2L0 MR READ 
MDISK 194 3340 106 044 CPV2L0 MR READ 
MDISK 199 3340 029 001 CPV2L0 »R READ 
MDISK 193 3340 001 030 0SERD1 MR READ 
MDISK 294 3340 031 030 0SERD1 MR READ 
MDISK 393 3340 061 060 DSERD1 MR READ 
MDISK 394 3340 121 060 USERD1 MR READ 
MDISK 390 3340 181 002 0SERD1 MW READ 
MDISK cuu 3340 000 348 yyyyyy MW 

where cuu and yyyyyy are the address and lakel cf your system residence 
voluie defined in your DMKSYS nodule. 

The entries in the preceding VM/370 directory, with the exception of 
the 192, 294, 393, 394, and 390 virtual disks, are included in the 2314, 
3330, and 3340 VM/370 directories supplied with the starter system, and 
should be included in your VM/370 directory, as they are used by IBM for 
support. 

The contents of the preceding virtual disks are: 

Disk Contents 

T90 Current CMS system disk 

191 Work area 

194 CP text retention 

199 The 191 minidisk (work area) 

193 CMS PTFs, updates, and updated text decks (object modules) 

294 CP PTFs, updates, and updated text decks (object modules) 

393 CBS source and macros 

394 CP source, macros, and copy files 
390 CMS test nucleus area 

cuu CP system residence device, or a replica of it, for test 
purposes 



These virtual disks are shown in Figure 27. 



You should apply all distributed updates. Once you create the 
appropriate files, you should access the disks containing the CP, CMS, 
or RSCS source files and update procedures, and apply the updates. 

To apply the IBM distributed updates to an existing source file, use 
the VMFASM EXEC procedure. To apply the IBM distributed updates to a 
copy or macro file, use the VMFMAC EXEC procedure. 

If you update a copy or macro file, you should use the VMFASM EXEC 
procedure to reassemble the module (s) that contain that copy or macro 
file. 
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HSCS Generation Procedure 





CP 

SOURCE, 

MACROS, 

AND 

COPY 

V FILES J 



WORK 
AREA 




r 

< 




CP 

PTFS 

AND 

UPDATES 



199 



CPGEN'S 
191 



CMS 
SOURCE 

AND 
MACROS 




CMS 

PTFS 

AND 

UPDATES 





CP 

TEXT 

RETENTION 



RSCS SYSTEM 
DISK (THE RSCS 

VIRTUAL 

MACHINE'S 191 

DISK, LINKED TO 

MAINTAS195) 






CP 

SYSTEM 

RESIDENCE 



RSCS 

TEXT 

RETENTION 



Figure 27. System Support Plan 
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Updating Modules Using the VMFASM EXEC Procedure 



Use the VMFASM EXEC procedure to update a specified source file 
according to entries in a control file, and to assemble the updated 
source file. VMFASM invokes the CMS UPDATE command. The format of the 
VMFASM command is: 



VMFASM I fnl fn2 [ (options. ..[)] ] 

0£ t ions : 

r T r n r i 

I DISK I I TERM I I LIST | 
IPBIHTl INOTEBMI | NOLI ST | 

L J L J L J 

r T r T 

I DECK I I BENT | 
I J C DEC K I I NO BEN T | 

L J t ~ J 



w h er e : 

fn1 is the filename of the source file to be updated. 

fn2 is the filename of the control file. The control file must have 
a filetype of CNTBL. 

0£ ti on s : 

DISK 

PBINT 

TERM 

NOTERM 
LIST 



places the LISTING file on a virtual disk. 

writes the LISTING file to the printer. 

writes the diagnostic information on the SYSTERM data set. The 
diagnostic information consists of the diagnosed statement 
followed by the error message issued. 



suppresses the TERM option, 
produces an Assembler listing. 



NOLIST does not produce an Assembler listing, 

DECK writes an object module on the device specified on the FILEDEF 
statement for PUNCH. 

NODECK suppresses the DECK option. 

RENT checks the program for a possible violation of program 
reenterability. Code that makes the program nonreenterable is 
identified by an error message. 

I NORENT suppresses the RENT option. 
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I 2.SING VMFASM TO APPLY IBM-SUPPLIED UPDATES 

The control file contains records that identify the updates to be 
applied and the macro libraries, if any. needed to assemble the source 
program. The updates are applied starting with the last update file in 
the control file and in sequence up to the first update file (or the 
update file inmediately following the MACS record) . Updates identified 
by auxiliary files are applied starting with the last update in the 
auxiliary file and proceeding in sequence up to the first. 

For example, a control file named UPDATE1 CNTRL contains the 
following two records: 

TEXT MACS DMKMAC CMSLIB OSMACRO 
IBM1 AUX2000 

An Assembler Language source file is named DHKVAT ASSEMBLE* 

An auxiliary file named DMKVAT AUX2000 contains a list of filetypes 
(NEH2 and NEW1) with NEW2 the first entry and NEH1 the last. 

The two update files are named DMKVAT NEW1 and DMKVAT NEH2. These 
are the files identified by the auxiliary file, DMKVAT AUX2000. Assume 
these files contain IBM-supplied updates to DMKVAT, such as inserted, 
deleted, or replaced source statements and the appropriate control 
statements. The update control statements are described in the VM/370 : 
Command LaBa!i§3§ guide for General Users with the CMS UPDATE command. 

To update DMKVAT, you enter the command: 

VMFASM DMKVAT UPDATE1 

VMFASM does the following: 

• VMFASM locates the DMKVAT ASSEMBLE and UPDATE1 CNTRL files. 

• The UPDATE1 CNTRL file is processed from the bottom up. The first 
entry found is IBM1 AUX2000. 

accessed disks. 

• When VMFASM locates the DMKVAT AUX2000 file, it processes it from the 
bottom up. The first entry found is NEWl. 

• VMFASM tries to locate the the update file named DMKVAT NEWl. When it 
finds DMKVAT NEWl, VMFASM applies the updates that are in DMKVAT NEWl 
to the DMKVAT ASSEMBLE file, and creates a new file called $DMKVAT 
ASSEMBLE. 

• Next, VMFASM processes the NEW2 entry in the DMKVAT AUX2000 file. 
When VMFASM locates the update file DMKVAT NEW2, it applies the 
updates to the updated ASSEMBLE file ($DMKVAT) . 

• Because there are no more filetypes listed in the DMKVAT AUX2000 
file, VMFASM reads the next control record in the UPDATE1 CNTRL file. 
In this case, it is the MACS record. 

• After entering the macro library names that are on the MACS record 
into the appropriate Assembler library lists, VMFASM assembles the 
updated ASSEMBLE file ($DMKVAT) . 

• The UPDATE command then stacks in the console read buffer the uplevel 
(update level identifier) associated with the last update applied. If 
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there were no updates, it stacks the uplevel associated with the MACS 
control record and the naies of the nacro libraries specified in the 
MACS record. VMFASM then reads the stacked lines and concatenates the 
uplevel (if it is not TEXT) to the characters TXT to form the 
filetype of the assenbled updated source. 

An update level identifier of TEXT causes special handling in the 
VMFASM EXEC procedure, whether or not an update is used with it. A 
name of TEXT is used as the object module filetype without level 
identification concatenation. Thus, TEXT becomes the filetype. 

VMFASM places the macro library names that were specified on the MACS 
record in the Assemble library list (via the CMS GLOBAL command) so 
that those libraries can be used when the updated source file is 
assembled. 

In this example, the last (and only) update applied was identified as 
IBM1 AUX2000, The file identification for the updated source is 
DMKVAT TXTIBM1. The updated source is assembled using the macro 
libraries DMKMAC, CMSLIB, and OSMACHO. 

You may want, on occasion, to have entries in a control file that 
specify an update level identifier but no update. A record of the 
following format, for example, is allowed: 

NAMES 

because the control file is used for loading object modules (text decks) 
as well as for updating input files. 

If updates are not found, a message is issued and processing 
continues, if possible. 



OSING VMFASM TO APPLY YOUR OWN UPDATES 

If you wish to apply your own update to VM/370 (for example, if you wish 
to expand the accounting routines) , you follow the same procedure 
described for applying IBM-supplied updates. 

You create the update file. You can name the update file in either of 
two ways. If you are going to identify the update file directly in the 
control file, use the form: 

DMKACO UPDTupid 

where DMKACO is the filename of the accounting module you wish to 
expand, and upid is the identification for the filetype. For example, 
you might call your update file: 

DMKACO 0PDTFIX1 

The second way to identify your update is via an auxiliary file. If 
you use an auxiliary file, you use the following form to name your 
update file: 

DMKACO ft 

where DMKACO is the filename of the accounting routine you wish to 
expand and ft is any filetype. 
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For example, you could have two update files called: 

DMKACO NEH1 
DHKACO NEW2 

When you decide to use an auxiliary control file, it Bust have a name in 
the form 

DMKACO AUXnnnn 

For example, assume you have an auxiliary control file called: 

DHKACO AUXnil 

This AOX file has the following entries (the filetypes of your update 
files) : 

MEH2 
NEW1 

Mext, you must create a control file to identify all IBM-supplied 
updates to the module you are changing and your own updates. You must 
apply the IBH-supplied updates first. Assume there are IBM-supplied 
updates in an auxiliary file called: 

DHKACO AUXB20 

and that your own updates are those used as examples in the preceding 
paragraphs. Then, you need your own control file, identified as: 

fn CNTRL 

It can have any filename, but its filetype must be CNTRL. For this 
example, the control file is called: 

LOG CNTRL 

and it has the following records: 

TEXT HACS DMKMAC 
LOCAL FIX1 
SPEC AUX1111 
IBH1 AUXR20 

I To apply the updates to DHKACO, issue the command: 

VHFASH DHKVAT LOC 

The VHFASH procedure handles the update as follows; it: 

• Locates the source file, DHKACO. 

• Locates the control file, LOC CNTRL. 

• Reads the control file, last line first (IBH1 AUXR20) . 

• Locates the IBH-supplied auxiliary file, DMKACO AUXH20. 

I • Reads the DHKACO AUXR20 auxiliary file from bottom to top and applies 
I the IBH-supplied updates to DHKACO, naming the updated source $DHKACO 
I ASSEHBLE. 

I • Reads the next entry in the control file (SPEC A0X1111). 
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I • Locates your own auxiliary file, DMKACO AUX1111. 

• Beads the last entry (NEW1), locates the update file DMKACO NEK1, and 
applies the update to the updated source $DMKACO. 

• Reads the next entry in your auxiliary file (MEW2) , locates the 
corresponding update file DMKACO NEW2, and applies it to the updated 
source SDMKACO. Processing for your auxiliary file is now complete. 

• Reads the next entry in the control file (LOCAL FIXl). 

• Locates the directly-identified update file, DMKACO DPDTFIX1. 

• Applies the DMKACO UPDTFIXI updates to the updated source ($DMKACO) . 

• Reads the next control record, the MACS record. 

• Issues the GLOBAL command for the macro libraries identified on the 
MACS record (DMKMAC MACLIB) . 

• Assembles the updated source file, $DMKACO ASSEMBLE. 

• Names the object module DMKACO TXTLOCAL. The filetype is derived by 
concatenating the prefix (TXT) and the uplevel of the last update 
applied (LOCAL) . 

If you create a new object module for a VM/370 module, you must also 
I reconstruct the CP, CMS, or RSCS nucleus using the VMFLOAD service 
program. Or, if the file is a part of a CMS command module, use the 
CMSGEND procedure to generate a new module utilizing the new object 
code. See Appendix D to determine whether the CMS nucleus or some other 
MODULE files must be generated again because of your update. 

When you use CMSGEND to create a new module, you must change the 
filetype of the object deck to TEXT (if it is not already TEXT) before 
issuing the CMSGEND command. After the CMSGEND processing is complete, 
you can change the filetype of the object deck back to what it was 
before. 

Note that CMSGEND renames the existing module to "fname MODOLD" 
before creating the updated module. This ensures that any users 
currently using the CMS system do not have their processing interrupted 
by the updating of modules, because the SSTAT (system status table) of 
the loaded system is still pointing to the area on the system disk 
occupied by the renamed module. When the system is reloaded, the SSTAT 
I points to the updated module, and the old module can be erased. 

I OTHER FILES PRODUCED BY VMFASM 

I VMFASM invokes the UPDATE command, which produces two output files that 
I indicate which updates were applied. The file 

I fn UPDATES 

I lists the names of update files that were applied to the source file 
I (fn) and the file 

I fn UPDLCG 

I lists the actual updates that were applied to the source file (fn) and 

I error messages. Both of these files are included in the LISTING file, 

I and precede the program source statements. Also, the file (fn UPDLOG) 

I precedes the object code in the text file. 
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Using the VMFMAC EXEC Procedure to Update Macro Libraries 



Use the VMFMAC EXEC procedure to update macro libraries. It invokes the 
CMS UPDATE command to update specified copy or macro files, according to 
entries in a control file, and then builds a new macro library from the 
resulting new versions of those files. 

The format of the YMFMAC command is! 



! VMFMAC ! libname control ! 

I 1 

where : 

libname is the filename of an EXEC file that contains the filenames of 
macro or copy files to be updated. The entries in the libname 
file are in the following format: 

&1 &2 fnamel 
SI S2 fname2 



where fnamel, fname2, and so on, are filenames of macro or 
copy files to be updated and included in the macro library 
(MACLIB) . 

control is the filename of a control file to be used to apply the 
updates. The filename is usually DMSnnn, DMKnnn, or DMTnnn, 
and the filetype must be CNTRL. 

VMFMAC finds the EXEC file specified by libname, and invokes the CMS 
UPDATE command to apply updates, in the order indicated by the control 
file, to the macro or copy files listed in the libname EXEC file. VMFMAC 
then builds a new macro library containing the updated files. 

VMFMAC produces two files: libname MACLIB and libname COPY. The file, 
libname MACLIB, is the new macro library. The file, libname COPY, 
contains a list of the updates applied to each macro. The update log and 
a copy of the updated macro is printed. 

If a file named libname MACLIB already exists, VMFMAC renames it 
libname OLDMAC. However, if libname OLDMAC already exists, processing is 
terminated. 

If a file named libname COPY already exists, VMFMAC renames it 
libname OLDCOPY. However, if libname OLDCOPY already exists, processing 
is terminated. 

Copy files should contain •♦COPY copyname' as the first record. If 

this record is not included, the copyname for the member becomes the 

filename used in the MACLIB command that added the member. This allows 

copyname to be put in the MACLIB directory regardless of the filename of 
the copy file. 

If any errors are encountered during the update process, processing 
terminates. 
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Using VMFLOAD to Generate a New Nucleus 



I Use the VBFLCAD program to generate a new CP, CMS, or RSCS nucleus. The 
VMFLOAD program uses two files, a loadlist EXEC file and a control file, 
to produce a punch file that has several object modules. VMFLOAD 
requires a virtual machine with 320K. 

The format of the VMFLOAD command is: 



I VMFLOAD I loadlist control 

I 



w h er e : 
loadlist 



is the filename of an EXEC file that contains the names of 
object modules in the order in which they are to reside in the 
complete load file for the nucleus. For example: 



8C0NTR0L OFF 

SI &2 &3 filename [filetype] 

&1 62 S3 filename [filetype] 



control 



The filename is the name of an object module to be punched. 
The object modules are punched in the order specified. If a 
filetype is specified, VMFLOAD searches for that specific 
file, and, if it finds it, punches it without a header card. 

If the filetype is not specified in the loadlist, VMFLOAD uses 
the control file to determine which object module is the 
highest level object module available. VMFLOAD searches the 
control file from top to bottom. When it finds the 
appropriate object module, VMFLOAD punches it. 

is the filename of the control file. This is usually the same 
control file used to apply updates to modules via the VMFASM 
or UPDATE commands. This file identifies the highest level 
object module available, if the filetype is not specified in 
the loadlist. 



The VMFLOAD 
upon completion 
CONT command is 
deck. The comm 
completion. You 
punched output 
reader file. If 
write an EXEC 
that EXEC proce 



program displays a confirmation message or error message 
. Before the loadlist procedure is invoked, a SPOOL PCH 

executed to ensure that the punched files appear as one 
ands SPOOL PCH CONT and CLOSE PCH are executed upon 

may wish to specify SPOOL PCH TO userid to transfer the 
as a file to your own (or another) virtual machine as a 

you want to perform any additional controls, you should 
procedure to perform the control and invoke VMFLOAD from 
dure. 



USING VMFLOAD 



VMFLOAD searches the control file for the desired object modules in the 
order in which the identifiers are specified in the file, from top to 
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I bottom. Bemember that the updates were applied from bottom to top; the 
I last update applied is the one immediately following the MACS record, 
I and so on from top to bottom. For example, consider a control file, 
named LOC CHTBL, of the following format: 

TEXT MACS DMKMAC 

LOCAL FIX1 
I SPEC ADX1111 
I IBH1 AUXB20 

In addition, suppose that the following object modules are on disk: 

I DMKACO TEXT 

I DMKACO TXTIBM1 

I DMKACO TXTSPEC 

DMKACO TXTLOCAL 

DMKPSA TEXT 

DMKSLC TEXT 

DMKMCH TXTIBM1 

DMKMCH TEXT 

I DMKCKP SPEC 

I DMKCKP IBM1 

I DMKCKP TEXT 

And finally, assume that the loadlist called PABTIAL EXEC contains 
the following entries: 

61 &2 63 DMKLDOOE LOADEB 

&1 82 83 DMKPSA 

8 1 82 83 DMKSLC 

81 82 83 DMKMCH 

I 81 82 83 DMKACO 

I 81 82 83 DMKCKP 

When you issue the command VMFLOAD PABTIAL LCC, the VMFLOAD program 
punches the loader (DMKLDOOE) , and then punches the object modules in 
the following order: 

DMKPSA TEXT 
DMKSLC TEXT 

nMV'Mr'U TVTTnMl 

■iy &J A\ LJ V^ U A. J^ ^ Jm ±J k* t 

I DMKVAT TXTLOCAL 
I DMKCKP TXTSPEC 

The first file located that corresponds to the update level 
identifier LOCAL is punched, and all lower level files are ignored. If 
no file with a filetype of TXTLOCAL is found, VMFLOAD next searches for 
one with a filetype of TXTSPEC, then for one with a filetype of TXTIBM1, 
and lastly for a file with a filetype of TEXT. If the end is reached 
without finding a TEXT file, VMFLOAD displays the message: 

•filename TEXT' NOT FOUND 

and continues processing the next entry in the loadlist. 

Thus, you can have a completed load file with object modules of 
varying levels. You are responsible for determining the validity of the 
completed load file. 

The distributed system uses a loadlist named CPLOAD for the CP 
I nucleus without virtual=real support, VBLOAD for the CP nucleus with 
I virtual=real support, CMSLOAD for the CMS nucleus, and DMTLOAD for the 
I BSCS nucleus. For example, to generate a CP nucleus, issue: 

VMFLOAD CPLOAD DMKnnn 
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The loadlist, CPLOAD, contains first the loader, next all the 
nonpageable CF modules and lastly, the pageable CP modules. VHFLOAD 
first finds DMKLDOOE (the loader) and punches it to the virtual punch. 
It then finds the highest levels of the other object modules named in 
CPLOAD (the highest level is determined by the control file, DMKnnn) and 
punches them to the virtual punch. If both a filename and a filetype 
are specified in the loadlist, the specified file is considered the 
highest level. If you issue the command "SPOOL PON TO userid", the 
completed load deck is transferred to the virtual card reader of the 
userid specified. When you IPL that virtual card reader, the loader is 
read first, and it loads the rest of the object modules. If the loader 
is successful in its operation, the nucleus is written on the system 
residence device, if that device is available. 



CP IjCADLIST REQUIREMENTS 

The CPLOAD loadlist EXEC contains a list of CP modules that is used by 
the VMFLOAD procedures to punch the text decks for the CP system. All 
modules following DMKCPfe in the list are pageable CP modules. Each 4K 
page in this area may contain one or more modules. Pageable modules must 
not span the 4K page boundaries. The module grouping is governed by SPB 
(Set Page Boundary) cards that are assembled in the pageable modules. An 
SPB card is a loader control card that forces the loader to start this 
module at the next higher UK boundary (a 12-^2-9 multipunch must 
immediately precede the 'SPB' characters) . If more than one module is 
to be contained in a 4K page, only the first is assembled with an SPB 
card. The second and subsequent modules for a multiple module UK page 
must not contain SPB cards. 

The loader inserts SPB cards automatically where they are needed; you 
do not have to insert SPB cards. 

If you change the loadlist, be sure that any modules loaded together 
in the pageable area do not exceed the UK limit. Page boundary crossover 
is not allowed in the pageable CP modules. 

The position of two modules in the loadlist is critical. All modules 
following DMKCPE must be reenterable and must not contain any address 
constants referring to anything in the pageable CP area. DMKCKP must be 
the last module in the loadlist. 
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The Loader 



The loader is a service program that loads a CP, CMS, or RSCS nucleus, 
and produces a load nap. There are three loaders. DMKLDOOE is the name 
of the CP loader, DMTLDOOE is the name of the RSCS loader, and DMSLBOOE 
is the name of the CMS loader. The CP and RSCS loaders are identical, 
except for the name. The CMS loader is similar to the CP loader; 
however, it contains only the function necessary to load CMS. The CP 
loader loads the object modules (TEXT files) supplied with it, resolves 
CCH addresses, and resolves address constants. The same loader is used 
whether a virtual=real or standard CP system is generated. 

If overlay error occurs while the loader is executing, define a 
larger virtual machine and reload the system. 

The loader is distributed with the following default I/O addresses: 

Console=009 
Printer=OOE 

You can override these addresses by placing a control card between the 
last card of the loader and the first card of the text decks. The format 
of the control card is: 

Column Contents 

1 12-2-9 lultipunch 

2-U DEV 

5 blank 

6-13 PRHT=cuu (cuu is the printer address) 

14 blank 

15-22 TYPW=cuu (cuu is the console address) 

The other loader control statements are the same as the loader 
control statements described with the CMS LOAD command in the VM/370: 
Command Lan^uacje Guide for General Users. 

The loader is self-relocating, that is, it is initially loaded at 
address 2000 (hexadecimal) ; it then relocates itself at the top of 
storage. (For example, if the size of the loader is 10K, and the real 
storage size of the CPU is 512K, the loader occupies the area of storage 
between 502K and 512K.) As the loader needs free storage to perform its 
operations, it extends downward through storage. 

The object modules being loaded must not overlay either the loader or 
any address between zero and 100 (hexadecimal). The object modules are 
loaded into storage in a positive direction (that is, upward through 
storage) . Before the loader actually loads an object module, it checks 
that the module does not overlay the loader's free storage. If an object 
module would overlay the loader, the loader terminates. You must close 
the printer to get the load map printed. The last line of the load map 
indicates the overlay area, if there was one. 

If the loader terminates the operation, one of the following wait 
conditions is indicated in the instruction counter: 



Counter Condition 

X'111111' A program check occurred 

X'BBBBBB' A machine check occurred 

X'999999' An SVC was issued 
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The interruption codes for an SVC wait state are: 

Code Meaning 

100 Bad hexadecinal to binary conversion 

101 No free storage remaining 

102 Duplicate entry type 1 card. 

103 The "naae" in the LDT card is undefined. 

104 Control section not found by EOF. 

105 Reference table overflow. 

106 Trying to overlay the loader. 

107 Trying to overlay an address between zero and 100. 

108 Permanent I/O error from the input device. 

109 Loader releasing storage that is not on a doubleword 

boundary. 



THE LOAD MAP 

The load map (the output of the loader) indicates: 

• The size of each object module and the address where it is loaded. 
For example: 

DMKMCH AT 00E68 MODULE SIZE IS OOOCOO 

• The end of the resident nucleus with the message: 

*** *** 

END OF VM/370 RESIDENT NUCLEUS 
*** *** 

The CP modules that precede this message in the load map are not 
pageable; the CP modules that follow this message are pageable. 

• When a Set Page Boundary (SPB) card has been inserted. If an object 
module cannot fit on the same page as the object module (s) loaded 
before it, the loader inserts an SPB card to force the modules to be 
loaded at a page boundary. This procedure ensures that object modules 
do not cross page boundaries. 



I GENERATING A NEW LOADER 

I The loader service program, in its executable form, has a filetype of 

I LOADER. Whenever you assemble a new copy of DHKLDOOE, you must 

I convert the resulting text file to a loader file. If there is a 

I virtual punch at address OOD and a virtual reader at address OOC, the 

I procedure for generating a new loader is: 



I STEP 1. ASSEMBLE THE NEW LOADER 

I Update and assemble DMKLDOOE. The output from this assembly is 
I DMKLDOOE TEXT. 
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STEP 2. PUHCH A COPY OF THE OLD LOADER 



I Spool the punch continuously and punch a copy of the old loader. 

I SPOOL OOD * COST 

I PUNCH DHKLDOOE LOADER (NOH 



I STEP 3. PUHCH A COPY OP THE MEW LOADER TEXT FILE 

I Punch a copy of the newly-assembled loader, then close the punch. 

i When the punch is closed the two files (DHKLDOOE LOADER and DHKLDOOE 

I TEXT) are sent to your reader. The commands to punch the new loader 

I text file and close the punch file are: 

I PUNCH DHKLDOOE TEXT (NOH 

I SPOOL OOD * NOCONT CLOSE 



I STEP 4. LOAD THE NEW LOADER 

I IPL your virtual reader to read the old version of the loader 

I (DHKLDOOE LOADER) into your virtual machine. Then the old loader 

I reads the new loader text file into your virtual machine and creates 

I the new loader file. 

I IPL OOC 

I When the IPL is complete, the message 

I DHKDSP450W CP ENTERED; DISABLED WAIT PSW 

I is issued. The instruction address in the disabled wait PSW is 

I X«404040'. 



STEP 5. PUNCH A COPY OF THE NEW LOADER (EXECUTABLE FORH) 

Close the punch to punch a copy of the new loader, which was created 
in Step U. 

CLOSE OOD 



I STEP 6. NAME THE NEW LOADER DHKLDOOE LOADER 

I IPL CMS and read the file you punched in Step 5. Name this file 

I DHKLDOOE LOADER; this replaces the original DHKLDOOE LOADER file with 

I the new one. 

I IPL CHS 

I READ DHKLDOOE LOADER 

I Note: Save a copy of the original DHKLDOOE LOADER file before you 

I replace it with the updated loader. 
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Using the GENERATE EXEC Procedure to Generate a New CP or 

CMS Nucleus 



Use the GENERATE EXEC procedure to generate a new CP or CMS nucleus 
without performing the entire VM/370 system generation. GENERATE can: 

• Build a new VM/370 directory. 

• Assemble a new real I/O configuration file (DHKRIO) . 

• Assemble a new CP system control file (DMKSYS) . 

• Assemble a new forms control buffer load (DMKFCB) . 

• Assemble a new system name table (DMKSNT) . 

• Place a standalone version of the VM/370 service programs on disk. 
You can create a standalone version on disk of one or all of the 
following: 

— The Directory service program (DMKDIR) 

— The DASD Dump Restore service program (DMKDDB) 

— The Format/Allocate service program (DMKFMT) 

• Create a standalone punch file of the VM/370 service programs. You 
can create a punch file for one or all of the following: 

— The Directory service program (DMKDIR) 

— The DASD Dump Restore service program (DMKDDR) 

— The Format/Allocate service program (DMKFMT) 

— The IBCDASDI Virtual Disk Initialization service program 

• Generate a CP and/or CMS nucleus and, optionally, load them. 

Instructions for coding the control statements and macros that define 
your VM/370 directory, and DMKRIO, DMKSYS, and DMKSNT files are in "Part 
2: Defining Your VM/370 System." Instructions for coding a new DMKFCB 
module are in the VM/370: System Programmer' s Guide. 

The GENERATE EXEC procedure assumes the following: 

Virtual tape address = 182 
Virtual address of CMS build area =190 
Virtual address of CP build area = 19U 
Virtual card reader = OOC 

The format of the GENERATE EXEC command is: 
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VM370 

DIRECT [OHLY] 
DMKRIO [ONLY] 
DMKSYS [ONLY] 
DMKFCB [ONLY] 
DMKSNT [ONLY] 
IFLDECK 
SRVCPGM 

r T 

|CP I NUCLEUS [NOLOAD] 
I CMS I 

L J 



where : 
VM370 



builds a new VM/370 directory, assembles DMKRIO and 
DMKSYS (also assembles DMKFCB and DMKSNT, if they are 
supplied) , writes the CP nucleus to tape and optionally 
loads it. 

You must have the appropriate files in your virtual card 
reader at address OOC. Place the following in your card 
reader, in the order shown: 

:READ fn DIRECT 

(Directory program control statements) 

:READ DMKRIO ASSEMBLE 

(real I/O configuration macros) 

:READ DMKSYS ASSEMBLE 

(CP system control macros) 

where fn is the filename of your VM/370 directory. 
Optionally, you can place new versions of DMKFCB and/or 
DMKSNT in your card reader following the DMKSYS macros: 

:READ DMKFCB ASSEMBLE 

(forms control buffer load macros) 

:READ DMKSNT ASSEMBLE 

(system name table macros) 



GENERATE reads the files in 
Directory program to build 
invokes the VMFASM EXEC pro 
ASSEMBLE files in the reader, 
current IBM supplied contro 
proper macro libraries are av 
assembled and to assign th 
GENERATE invokes the VMFLOAD 
the CP object modules on tape 
error is detected during any 
GENERATE terminates at the en 



the reader. It invokes the 

the VM/370 directory and 

cedure to assemble all the 

VMFASM is invoked with the 

1 file to ensure that the 

ailable when the modules are 

e correct filetype. Then, 

EXEC procedure to place all 

in the correct order. If an 

of these processing steps, 

d of that step. 



For a CP nucleus without a virtual=real area, GENERATE 
loads the tape, thus loading the newly generated CP 
nucleus. For a CP nucleus with a virtual=real area, 
GENERATE writes the nucleus to tape and exits. You are 
instructed to shutdown the system. Then you can IPL the 
tape on a real machine or on a virtual machine that has 
enough virtual storage. The "Specifying a Virtual=Real 
Machine" section of Part 1 tells you how much virtual 
storage you need. 
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DIRECT [ONLY] builds a new VM/370 directory. 

If you do not specify ONLY, GENERATE executes exactly as 
if you specified GENERATE VM370. 

If you specify ONLY, only the VM/370 directory is built. 
You must place the Directory program control statements 
in your virtual card reader at address OOC, as follows: 

:READ fn DIRECT 

(Directory program control statements) 

where fn is the filename of your VM/370 directory. 

DMKRIO [ONLY] assembles the real I/O configuration file (DMKRIO) by 
invoking VMFASM, 

If you do not specify ONLY, the GENERATE EXEC procedure 
executes just as if you specified GENERATE VM370 (except 
that it does not build a new VM/370 directory) . 
Conseguently, you should follow the directions for 
issuing GENERATE VM370, except do not place the Directory 
program control statement (nor the corresponding :READ 
statement) in your card reader. 

If you do specify ONLY, only the DMKRIO module is 
assembled. You must place the real I/O configuration 
macros in your virtual card reader at OOC, as follows: 

:READ DMKRIO ASSEMBLE 

(real I/O configuration macros) 

DMKSYS [ONLY] assembles the CP system control file (DMKSYS) by invoking 
VMFASM. 

If you do not specify ONLY, the GENERATE EXEC procedure 
executes just as if you specified GENERATE VM370 (except 
that it does not build a new VM/370 directory and does 
not assemble a new dmkrio) . Conseguently , you should 
follow the directions for issuing GENERATE VM370, except 
do not place the Directory program control statements or 
real I/O configuration macros (nor their corresponding 
:READ statements) in your card reader. 

If you do specify ONLY, only the DMKSYS module is 
assembled. You must place the CP system control macros in 
your virtual card reader at OOC, as follows: 

:READ DMKSYS ASSEMBLE 

(CP system control macros) 

DMKFCB [ONLY] assembles the forms control buffer load (DMKFCB) by 
invoking VMFASM. 

If you do not specify ONLY, the GENERATE EXEC procedure 
executes just as if you specified GENERATE VM370 (except 
it does not build a new VM/370 directory and does not 
assemble new DMKRIO or DMKSYS modules. Conseguently, you 
should follow the directions for issuing GENERATE VM370; 
except do not place the Directory control statements, 
real I/O configuration macros, or CP system control 
macros (nor their corresponding :READ statements) in your 
card reader. 
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If you specify ONLY, only the DBKFCB module is assembled. 
You must place the forms control buffer load macros in 
your virtual card reader at OOC, as follows: 

:EEAD DMKFCB ASSEMBLE 

(forms control buffer load macros) 

DMKSHT [ONLY] assembles the system name table (DMKSHT) by invoking 
VMFASM. 

If you do not specify ONLY, the GENERATE EXEC procedure 
goes on to invoke the VMFLOAD EXEC procedure to place all 
the CP object modules on tape. If no error occurs, and if 
the CP nucleus does not have a virtual=real area, 
GENERATE Then loads the tape, thus loading the CP nucleus 
(with the new version of DMKSNT) . 

If you do specify ONLY, the DMKSNT module is assembled, 
but the CP nucleus is not written to tape and is not 
loaded. 

To assemble DMKSNT, you must place the system name table 
macros in your virtual card reader, at address OOC, as 
follows : 

:READ DMKSNT ASSEMBLE 
(system name table macros) 

IPLDFCK creates the standalone service programs on disk from 
their associated object modules (text decks) . You are 
prompted to enter the names of the service programs you 
wish to generate. You can respond ALL, DDR, DIR, or 
FMT. If you respond ALL, the DASD Dump Restore, 
Directory, and Format/Allocate standalone programs are 
built on disk. 

SRVCPGM punches all the standalone service programs (DMKDIR, 
DMKDDR, DMKFMT, and IBCDASDI) . 

r T 

|CP I NDCLEOS [NOLOAD] 

jCMSI generates the CP or CMS nucleus. If you specify CP 

•- J NUCLEUS, the CP nucleus is loaded onto tape. 

For a CP nucleus without a virtual=real area, GENERATE 
loads the tape, thus loading the newly generated CP 
nucleus. For a CP nucleus with a virtual=real area, 
GENERATE writes the nucleus to tape and exits. You are 
instructed to shutdown the system. Then you can IPL the 
tape on a real machine or on a virtual machine that has 
enough virtual storage. The "Specifying a Virtual=Real 
Machine" section of Part 1 tells you how much virtual 
storage you need. 

If you specify CP NUCLEUS NCLOAD, the tape is not 
loaded. 

If you specify CMS NUCLEUS, a card-image deck is created 
and placed in the virtual card reader. GENERATE issues a 
prompting message to see if you want a card-image copy of 
the CMS nucleus put on disk. The card-image copy of the 
CMS nucleus is a file (CMSNUC NUCLEUS) that can later be 
loaded to create a CMS nucleus. If you specify CMS 
NUCLEUS NOLOAD, the new nucleus remains in the virtual 
card reader. 
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Using the VMFBLD EXEC Procedure to Build a New Nucleus 



Use the VHPELE EXEC procedure to build a new CP, CMS, or RSCS nucleus. 
The PLC (Program Level Change) tape must be mounted on a tape drive with 
an address of 181, and VMFBLD must be run from your C-disk. If these 
conditions are not satisfied, the following error messages are issued: 

•VMFBLD EXEC* ** NOT RUNNING ON THE 'C* DISK 
TAPE (181) NOT BEADY OR NOT ATTACHED ***** 

If you issue VMFBLD without an operand indicating which nucleus you 
want built, it prompts you with a message 

ENTER (CP|CMS|RSCS [BUILD]) 

Then you must enter CP, CMS, or RSCS to build a nucleus. 

The format of the VMFBLD command is: 



I r T 

VMFBLD I |CP I 

I I CMS I 

I IRSCS [BUILD]| 



where: 

CP builds the CP nucleus, incorporating the changes on the PLC tape. 

CMS builds the CMS nucleus, incorporating the changes on the PLC 
tape. 

RSCS loads RSCS text decks onto staging area and gives you the option 
of building the RSCS nucleus. 

RSCS BUILD 

builds the RSCS nucleus. This operand assumes that RSCS text 
decks are already loaded on the staging area. 



MIliEING THE CP NUCLEUS 

To build the CP nucleus, you must log on the software system support 
virtual machine and IPL CMS. If you used the VM/370 Directory program 
control statements supplied with the starter system, you log on as 
MAINT. Then when you issue 

VMFBLD CP 

VMFBLD prompts you to enter the staging area address 

ENTER CP STAGING AREA DISK ADDRESS: 

If you are logged on as MAINT, the 194 minidisk is your staging area. 
If an error occurs, VMFBLD displays the message 

ERROR ACCESSING SPECIFIED DISK 
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VHFBLD next proapts you with the message 

ARE YOU A BEW USEE? - RESPOND (YES|NO) 

You reply "yes" only when you are generating VH/370 from the starter 
system. The processing for the new user is described in "Part 3: 
Generating VM/370 (CP, CMS, and RSCS) ". You reply "no" if you already 
generated VM/370 from the starter system and later want to apply PLC 
updates. 

VMFBLD next asks: 

VIRTUA1=REAL OPTION REQUIREE (YES, NO) : 

If you reply "yes", you are prompted to enter the size of your 
▼irtual=real area: 

STORAGE SIZE OF VIRT=REAL [MINIMUM IS 32K]: 

The minimum size virtual =real area is 32K and the maximum is 4M. If the 
size you specify is not on a page boundary, it is adjusted to a page 
boundary and you are notified with the message: 

** SIZE ROUNDED TO NEXT HIGHER UK BOUNDARY ** 

VMFBLD displays the size of the virtual=real area: 

nnnnK STORAGE SIZE FOR VIRTUAL=REAL 
IS THE ABOVE ENTRY CORRECT (YES, NO) : 

If you reply "no", processing restarts by asking if you want the 
virtual=real option. 

VMFBLD can build a tape that can be loaded. It issues the message: 

GENERATE AN IPLABLE SYSTEM TAPE? — RESPOND (YES|NO) 

If you respond "yes", VMFBLD displays another message: 

MOUNT TAPE AS 182, HIT CARRIAGE RETURN WHEN READY 

You should mount a scratch tape on 182. If VMFBLD does not find a ready 
tape at 182, it issues the error message: 

TAPE (182) HOT READY OR NOT ATTACHED ***** 

You must ready or attach tape drive 182 to continue. 

VMFBLD can write the CP nucleus to disk, it prompts you: 

HRITE THE NUCLEUS TO THE SYSTEM DISK? — RESPOND (YES|NO) 

If you respond "no", VMFBLD terminates. If you respond "yes", the 
following messages are displayed: 

ROUTE LOAD MAP TO PRINTER OR READER? — RESPOND (RDR|PRT) 

If you respond "rdr", VMFBLD finishes building the CP nucleus and issues 
the messages: 

WHEN THE MESSAGE 'NUCLEUS LOADED ON 'xxxxxx* IS TYPED 

ISSUE THE COMMANDS 

CLOSE RDR ... (CLEARS THE READER) 

CLOSE PRT ... (BRINGS THE LOAD MAP TO THE READER) 

302 VM/370: Planning S System Generation Guide 



SPOOL PRT OFF ... (RESETS PRINTER SPOOL ADDRESS) 
SHUTDOWM THE SYSTEM AND IPL THE NEW CP SYSTEM 

If you respond "prt", VMFBLD finishes building the CP nucleus and issues 
the iDessdCies : 

WHEN THE MESSAGE 'NUCLEUS LOADED ON XXXXXX» IS TYPED 
ISSUE THE COMMANDS 

CLOSE RDR ... (CLEARS THE READER) 

CLOSE PRT ... (PRINTS THE LOAD MAP) 

SHUTDOWN THE SYSTEM AND IPL THE NEW CP SYSTEM 



SPECIAL CONSIDERATIONS FOR GENERATING A CP NUCLEUS WITH A VIRTnAL=REAL 
AREA 

If you generated a CP nucleus with a virtual=real area, you should check 
to see that there is enough virtual storage for you to IPL your nucleus 
in the virtual machine you are using. The "Specifying a Virtual=Real 
Machine" section of Part 1 tells you how to determine how much virtual 
storage you need. If you find that the software system support virtual 
machine that you are using does not have enough virtual storage, you 
should have VMFBLD generate a loadable CP nucleus on tape, but do not 
have VMFBLD write the nucleus to disk. To do this, reply "yes" to the 
guestion : 

GENERATE AN IPL'ABLE SYSTEM TAPE? — RESPOND (YES|NO) 

to create a loadable copy of CP on tape. Then respond "no" to the 
question: 

WRITE THE NUCLEUS TO THE SYSTEM DISK? -- RESPOND (YES | NO) 

and VMFBLD terminates. Then you should shutdown the system and load the 
new nucleus on the real machine or on a virtual machine that has enough 
virtual storage. 

lUliPIM IM CMS NUCLEUS 

To build the CMS nucleus, you must log on the software system support 
virtual machine and IPL CMS. If you used the VM/370 Directory program 
control statements supplied with the starter system, you log on as 
HAINT. Then you issue. 

VMFBLD CMS 

VMFBLD prompts you to enter the address of the CMS system disk with 
the message: 

ENTER CMS SYSTEM DISK ADDRESS: 
If an error occurs, the message 

ERROR ACCESSING SPECIFIED DISK 

is displayed. 

VMFBLD can punch the standalone programs; it prompts you with the 
message 

PUNCH STANDALONE SERVICE PROGRAMS — RESPOND (YES|NO) 
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If you reply "yes", VMFBLD punches the standalone programs and displays 
the following messages to indicate its progress: 

PUNCHIMG 'IPL FMT'****** 

PUNCHING 'IPL DIR'****** 

PUNCHING 'IPL DDR«****** 

PUNCHING 'IPL IBCDASDI ******* 

IPL DECKS EXIST AS CLASS 'B* PUNCH FILES 

If an error occurs punching the standalone service programs, VMFBLD 
displays the message: 

****ERROR PUNCHING 'IPL XXX***** 

VMFBLD continues by building the CMS nucleus. Also, if there are any 
updates on the PLC tape for the EREP program or the Assembler, VMFBLD 
updates those programs and creates the corresponding auxiliary 
directories. If an error occurs while VMFBLD is building the CMS 
nucleus, it issues one of the following messages: 

***ERROR READING PLC TAPE OR WRITING TO DISK a*** 
***ERROR CREATING THE CMS NUCLEUS*** 

If the nucleus is built successfully, VMFBLD issues the message: 

WHEN THE NEW CMS SYSTEM IS BUILT ISSUE: 
CLOSE PRT ... (PRINTS THE LOAD MAP) 



BDlIiPIMG THE RSCS NUCLEUS 

To build the RSCS nucleus, you must log on the software system support 
virtual machine and IPL CMS. If you used the VM/370 Directory program 
control statements supplied with the starter system, you log on as 
MAINT. Then issue: 

VMFBLD RSCS [BUILD] 

VMFBLD prompts you to enter the staging address: 

ENTER CP STAGING DISK ADDRESS 
194 

If you are logged on as MAINT, the 194 minidisk is your staging area. 
If an error occurs, VMFBLD displays the message 

ERROR ACCESSING SPECIFIED DISK 

If you did not specify BUILD on the VMFBLD command line, VMFBLD loads 
the DMTSYS ASSEMBLE file and all the RSCS text files and prompts you: 

DO YOU WISH TO BUILD RSCS SYSTEM — RESPOND (YES|NO) 

If you respond "no", VMFBLD processing is completed. If you respond 
"yes", processing continues as follows. 

If you specified BUILD on the VMFBLD command line or responded "yes" 
to the preceding prompting message, VMFBLD prompts you: 

ENTER RSCS SYSTEM DISK LINK PARAMETERS: 
USERID VADDR1 VADDR2 
rscs 191 195 

304 VM/370: Planning S System Generation Guide 



You should reply with the userid of your RSCS virtual machine, the 
virtual address of the RSCS system disk in the BSCS virtual machine, and 
a virtual address with which MAINT can access the RSCS system disk. If 
you did not enter all the needed parameters or if VMFBLD was not able to 
link to the BSCS system disk, one of the following error messages is 
displayed: 

MISSIMG PABABETERS — RE-ENTER 

ERROR LINKING TO userid vaddrl AS vaddr2 

If VuFBLD sains access of the RSCS system disk it cc^ies the DMTNPT- 
DMTSML, DMTAXS, and DMTLAX TEXT files from the CP staging area disk to 
the RSCS system disk and displays the message: 



TRANSFERRING 'RSCS' DISK RESIDENT TEXT 

If an error occurs, VHFBLD displays the message 

ERROR TRANSFERRING RSCS DISK RESIDENT TEXT FILE 

If no errors occur while VMFBLD transfers the RSCS files, it builds 
the RSCS nucleus. If an error occurs building the BSCS nucleus, VMFBLD 
displays the message 

*** ERROR CREATING THE RSCS NUCLEUS *** 
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Using the CMSGEND EXEC Procedure to Generate a CMS Module 



I Use the CMSGEHD EXEC procedure to generate a new CMS module from a TEXT 
I deck and place the new CMS module on the A-disk. Do not use CMSGEND to 
I generate the System Assembler (use ASMGEND for the Assembler) . 

I The format of the CMSGEND EXEC command is: 



r - 




r T 




^ 


1 CMSGEND 


fn 


1 CTLCMS 1 
1 CTLALL 1 
1 NOCLEAR 1 
1 MAP 1 
1 NOINV 1 






1 .. . , 




L J 




_. 1 



whe re : 
fn 



CTLCMS 



CTLALL 



is the filename of the TEXT file 
a CMS module. 



that is to be generated into 



The filenames that may be specified in the CMSGEND command 
are: ACCESS, COMPARE, COPYFILE, CMSBATCH, CPEREP, DDR, DIRECT, 
EDIT, FILEDEF, FORMAT, GENDIRT, GEN3705, GLOBAL, LISTDS, 
LISTFILE, MACLIB, MODMAP, MOVEFILE, NCPDUMP, PRINT, PUNCH, 
QUERY, READCARD, RELEASE, RENAME, RENUM, SAVENCP, SET, SORT, 
SVCTRACE, SYNONYM, TAPE, TAPPDS, TEXTLIB, TYPE, UPDATE, 
VMFDUMP, VMFLOAD, and ZAP. The preceding filenames include 
CBS commands and service programs. 

Note; You can also specify ASSEMBLE. when you specify 
ASSEMBLE, CMSGEND refreshes the Assembler's auxiliary 
directory. Use the ASMGEND EXEC procedure if you are updating 
assembler text decks or changing the mode. 

displays each CMS command as it is executed in the CMSGEND 
EXEC procedure. This is equivalent to the EXEC statement 
6CCNTBCL CMS. 

displays every executable statement as it is executed in the 
CMSGEND EXEC procedure. This is equivalent to the EXEC 
statement 6C0NTR0L ALL. 



NOCLEAR specifies that the CLEAR option 
CMSGEND invokes the LOAD command. 



is not to be issued when 



MAP 



specifies that the NOMAP option is not to be issued when 
CMSGEND invokes the GENMOD command. 



NOINV issues the NOINV option when CMSGEND invokes the LOAD command; 
this suppresses the displaying of invalid cards at the 
terminal. 
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Responses 

The CMSGEND EXEC procedure displays status and error messages. 

*** CURRENT STATUS: 

r T 

I 'fn MODULE A2' EXISTS | 

I'fn MODULE A2 • DOES NOT EXIST | 

L J 

r T 

I 'fn MODOLD A1' EXISTS | 

I I -Fn Mnnnin »1I nnpc: iinT wYTCfn i 

I .A-Ai t.1 ■^^ s^ \^ jj i^ ai &^v^.Ub^ uv^j. xjAjui^xj 

L J 

This message indicates whether a generated module already exists. 

*** LOADING: 

This message indicates that CMSGEND is loading the text decks. 

♦** (UNDEF. NAMES NORMAL FOR EDINIT) 

*** NOW WE HAVE A SECOND PASS FOE EDINIT MODULE. 

These messages indicate that the EDIT command requires two passes 
to resolve undefined names. 



*** RESULTS: 

[•fn MODOLD AT WAS ERASED] 

['fn MODULE A2 ' RENAMED TO 'fn MODOLD AT] 
•fn MODULE A2' CREATED FROM TEXT DECK (S) ... 
WITH ATTRIBUTES ... 

These messages indicate which existing modules were erased and 
renamed and tells which text decks were used to create the new 
module. 



ERROR OCCURRED. CMSGEND STOPS. 

This message indicates that an error occurred and that CMSGEND is 
terminated. 

INVALID ARGUMENT fn 

This message indicates that an invalid filename was specified on 
the command line. 
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I Using the ASMGEND EXEC Procedure to Generate the Assembler 



I Ose the ASWGESD EXEC procedure to build the System Assenbler and to 
I create the associated auxiliary directory, ASMGEND loads the text decks 
I for the Assembler in the correct overlay structure and produces a load 
I map. The format of the ASMGEND command is: 



, , , 

I I ASMGEND I I 

I L 1 



I l§s_Eonses 

I The ASMGEND EXEC procedure displays the following status and error 

I messages: 

I ENTEB TARGET DISK MODE FOR ASSEMBLE MODULES 

I DEFAULTS TO S-DISK IF NONE ENTERED 

I You enter the mode letter of the disk containing the modules 

I referred to from the auxiliary directory. If you enter a mode 

I letter, ASMGEND uses that mode letter as the "targetmode" operand 

I of the GENDIRT command when it creates the auxiliary directory. If 

I you do not specify a mode letter, S is used. 

I ASMGEND XF GEND COMPLETE 

I This message indicates that the System Assembler and its associated 

I auxiliary directory are generated successfully. 

I ASMGEND XF GEND FAILED 

I This message indicates that the System Assembler text files were 

I not loaded successfully. 



308 VM/370: Planning 6 System Generation Guide 



Recommended Procedures for Updating VM/370 



In order to preserve the integrity of VM/370 source and text files, you 

should keep updates and PTFs on a separate minidisk (not on the same 

disk as the original source and text files) . This minidisk should 

I contain the required IBM PTF updates from the latest PLC tape, updates 

I that you make (such as expanding the accounting routines or adding a 

I command to CP) , and the resultant text files containing the updates. You 

need access to the latest macro libraries. If you used the VM/370 

directory supplied with the starter system, the MAINT virtual machine 

has the CP library on the 194 minidisk and the CMS macro libraries on 

the 190 minidisk. 

You can use the MAINT virtual machine described in the "CP/CMS PTF 
Application Procedures" section and illustrated in Figure 27 to update 
VM/370. Note that that virtual machine configuration consists of the 
MAINT entry in the IBM-supplied VM/370 directory, with the addition of 
MDISK statements for virtual disks (193, 294, 393, 394, and 390). Figure 
27 shows the virtual disks described by the resultant MAINT entry. This 
virtual machine configuration should provide you with all the areas you 
need to update and test VM/370. 

You should not change the source (ASSEMBLE) files directly but 
instead use the CMS UPDATE command and the VMFASM and/or the VMFMAC EXEC 
procedures supplied with the VM/370 system. Also, you should not change 
the IBM-supplied auxiliary files nor the PTF (RxxxxDMK) files as these 
are controlled by the PLC procedure. 

If you want to update CP (for example, by adding your own command) , 
you should create your own control file. This file should contain 
entries for your updates, your auxiliary files and your text names, and 
also all the IBM-supplied entries describing the IBM-supplied auxiliary 
files. The following is an example of a control file called YOUROSN 
CNTRL: 

TEXT MACS DMKMAC USERLIB 

■ T rin » T T m 

TEXT AUXR20 

I Suppose you wish to update the main processor for CP commands 
I (DMKCFM) to add a module (DMKCMD) to process your new command. First you 
I must update DMKCFM. 

Log on as userid MAINT. Using the CMS EDIT command, with ASSEMBLE 
tab settings, create an update file. For this example, name the update 
file DMKCFM UPDTLCL. 

After you create the update file, access the CP PTF disk, the CP text 
retention disk and the CP source disk. The CP text retention disk (194) 
should contain the latest level of DMKMAC MACLIB. 

For example: 

ACCESS 294 B/A 
ACCESS 194 C/A 
ACCESS 394 D/A 
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FILE: CPLOADEXEC FILE: YOUROWN CNTRL 


&1 &2 &3 DMKLDOOE LOADER TEXT MACS MACLIB 


&1 &2 &3 DMKPSA LCLAUXLCL 


&1 &2 &3 DMKMCH TEXT AUXR20 


&1 &2 &3 DMKPRG 


&1 &2 &3 DMKPRV 


&1 &2 &3 DMKHVC 


&1 &2 &3 DMKDGD 


&1 &2 &3 DMKVAT 


&1 &2 &3 DMKIOS 


&1 &2 &3 DMKRNH 


&1 &2 &3 DMKGRF 


&1 &2 &3 DMKCNS 


&1 &2 &3 DMKTBL 


&1 &2 &3 DMKRSP 


&1 &2 &3 DMKDAS 


&1 &2 &3 DMKMSW 


&1 &2 &3 DMKIOE 


&1 &2 &3 DMKCCH 


&1 &2 &3 DMKRIO 


&1 &2 &3 DMKCFM 


&1 


&2 &3 LDT DMKSAVNC 














194 ^ 




294 ^ 




191 ^ 




DMKLDOOE LOADER 


DMKCFM TXTLOCAL 


DMKCFM TXTLOCAL 




DMKPSA TEXT 




DMKCFM AUXR20 




DMKCFM AUXLCL 






DMKMCH TEXT 




W9999DMK . . . 




LOCAL 02... 






DMKPRG TEXT 




DMKCFM AUXLCL 




LOCAL 01 ... 
DMKCFM LOCAL 02 
./ R . . . 






DMKCFM TEXT 




LOCAL 01 

DMKCFM W9999DMK 

./ R . . . 

DMKCFM LOCAL01 










CPLOAD EXEC 




./ 1 . . . 

YOUROWN CNTRL 

AUXLCL 

AUXR20 























Figure 28. Files for a System Update 
The CMS order of search is now: 

191 A R/H 

29a B/A H/0 

194 C/A R/0 

394 D/A B/0 

190 S R/0 

Update the source file and assemble the new source of DMKCFM: 

I VMFASM DMKCFM YOUROWN 

I VMFASM updates the DMKCFM ASSEMBLE file with all the PTFs in the 

I IBM-supplied auxiliary file for DMKCFM, and then updates it with your 

I own update file (DMKCFM UPDTLCL) . The updated source file is assemble 

I and the text file is named DMKCFM TXTLOCAL. 
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If you have several of your own updates to apply, you can use an 
auxiliary file to apply your updates. For example, the control file 
YOUROWN CNTRL could be: 

TEXT UACS DMKMAC CBSLIB USERLIB 
LOCAL AUXLCL 
TEXT AUXB20 

Your auxiliary file contains a list of the filetypes of update files to 
be applied. For example, your auxiliary file (DMKCFM AUXLCL) might look 
like: 

LOCAL02 
LOCAL01 

DMKCFM LOCAL01 
DMKCFM LCCAL02 

To update DMKCFM you must access the appropriate disks and issue the 
command : 

VMFASM DMKCFM YOUROWN 

VMFASM applies all the PTFs listed in the DMKCFM AUXR20 file and applies 
the two updates listed in your file (DMKCFM AUXLCL) . 

The IBM-supplied updates must be applied first; therefore, the entry 
in your control file identifying the IBM-supplied auxiliary file must be 
the last entry. Applying the IBM-supplied updates first ensures that 
the PTFs distributed by the VM/370 update service fit properly into the 
source files, as these are the same source files used by IBM. 

After you update DMKCFM, you must reload the CP nucleus. You also 
want to add your new module to the CP modules. Assemble your module. 
Then edit the CP Icadlist to include an entry for your module. Then 
punch a new CP nucleus by issuing: 

vnrijVJAU ^exsyjtku luununn 



BUILDING A CP KUCLEUS 

The following is an example of building and loading a new CP nucleus. 
The MAINT virtual machine is used because it has enough storage for the 
loader to execute (the loader needs 512K of virtual storage) . The MAIHT 
virtual machine also contains the ECMODE option so that you can test the 
system after you load it onto a replica of the system residence disk 
(which should be attached to your virtual machine as the same address as 
the real system residence disk) . 

You now spool your punch to yourself so that the card deck can be 
placed in the virtual reader instead of being punched on the real system 
punch. Before punching the nucleus to your virtual card reader, you must 
make sure there are no files in the punch or reader. You then issue the 
VMFLOAD command specifying the CPLOAD EXEC file containing the list of 
modules to be loaded, and also specifying a control file (for example, 
YOUROWN CNTRL) . 
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The sequence of conmands and system responses is: 
close pun 

R; 

close rdr 
R; 

pur rdr all 
NO FILES PURGED 

R; 

pur pun all 
NO FILES PURGED 

R; 

sp OOd * 

R; 

vmfload cpload yourown 

SYSTEM LOAD DECK COMPLETE 

PUN FILE 0821 TO MAINT COPY 01 NOHOLD 

R; 

The YOUROWN control file establishes both the filetype and order of 
search of the text files, and the CPLOAD EXEC establishes the filename. 
In Figure 28, note the reference to the DMKLDCOE LOADER in the first 
line of the CPLOAD EXEC. Because the filetype of LOADER is specified, 
the control file is not used to determine the filetype. CPLOAD searches 
all disks until the DMKLDOOE LOADER is found on the 194 disk. Then 
VMPLCAD punches the loader. Next, VMFLOAD searches for the DMKPSA 
TXTLOCAL text file. If it fails to find that text deck, VMFLOAD uses 
the next entry in the control file to determine the next possible 
filetype for DMKPSA. In this case, VMFLOAD searches for DMKPSA TEXT. 
When VMFLOAD finds the deck on the 194 disk, it punches it. This process 
is repeated for the next file, DMKMCH, and so on through the load list. 

When VMFLOAD begins searching for the filename (DMKCFM) , it finds a 
text deck called DMKCFM TXTLOCAL on the 191 disk. Note that a text with 
the same filename and filetype is also located on the 294 disk, but by 
accessing the 191 disk ahead of the 294 disk, a search priority is 
established. 

The DMKCFM TXTLOCAL text deck found on the 191 disk is the result of 
applying the three updates that are on the 294 disk (which are also 
contained in the DMKCFM text deck on the 2 94 disk) and the newest update 
on the 191 disk, which the following example tests. 

You can test an updated text deck before replacing an older version 
of that text deck. Once the newer text deck is tested, you may replace 
the older one with the newer version. 

Loading continues in a similar manner until all of the files 
specified in the CPLOAD EXEC are processed. At this time, the "SYSTEM 
LOAD DECK COMPLETE" message is displayed, and, as the punch is closed, 
the punch transfer message is also displayed. 

At this point the standalone loader is in the card reader, followed 
by all of the text decks necessary to construct a CP nucleus. There are 
two ways to handle this reader file. 

First, you can use the CMS MOVEFILE command to place the entire file 

on tape, thus creating a CP nucleus load tape which can be loaded into 

real storage. However, remember that the loader requires 512K of real 
storage. 
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The second way to handle the CP nucleus reader file is to IPL the 
loader in the card reader and actually load the nucleus onto the 330 
virtual disk, which is an exact copy of the real system residence 
device. To do this, issue the CP IPL command and specify a unit address 
of OOC^ Hhen the load o^-eration completes, the sessace "HDCLSUS LGADSD 
ON SYSRES" is displayed, followed by an error message indicating a 
disabled wait state PSW, the normal termination of the standalone loader 
program. 

ipl 00c 

NUCLEUS LOADED ON SYSRES 

DMKDSP450W CP ENTERED; DISABLED WAIT PSW 

CP 

Now, you must define your console address to be the same as defined 
in the RIOGEN macro in DHKRIO. Then IPL the system residence device, 
which is a virtual disk with an address of 330. (This procedure verifies 
that the nucleus runs on a virtual machine; this procedure is 
recommended, although it is not required.) 

def 009 as cuu 
CONS cuu DEFINED 
ipl 330 

The following example shows the new nucleus being loaded. The two 
error messages (both DMKLNK108E) are the result of not defining those 
disks as addresses which are contained in the virtual system's DMKRIO 
(Real I/O) deck. 

VM/370 VERSION 2 LEVEL 

NOW 14:53:07 EST THURSDAY 03/28/74 

CHANGE TOD CLOCK (YES | NO) : no 

14:53:50 DMKLNK108E CMSSYS 190 NOT LINKED; VOLID DDISK2 NOT MOUNTED 

RRRR. . « .RING. . . . GGGG 

14:53:50 DBKLNK108E OPERATOR 191 NOT LINKED; VOLID UDISKI NOT MOUNTED 

RRRR. . . .RING. . . .GGGG 

14:53:50 START ((COLD|WARM) (DRAIN) ) | (SHUTDOWN) : shutdown 

14:53:50 LOGON AT 14:53:50 EST THURSDAY 03/28/74 

14:53:50 LINE OIF LOGON AS OPERATOR USERS = 001 

DMKCPI960W SYSTEM WARM START DATA SAVED 

DMKCPI961W SYSTEM SHUTDOWN COMPLETE 

DMKDSP450W CP ENTERED; DISABLED WAIT PSW 
CP 

After you check the new CP, you may redefine your console and IPL the 
CMS system. After you IPL CMS, enter the DDR command and create a backup 
copy of the CP nucleus (which can be restored to the real system) . 
Define your input unit as the address of your system residence device. 
Your output unit is the tape (181) that is attached to your virtual 
machine. When you enter the DUMP statement with the NUCLEUS operand, DDR 
creates a copy of the nucleus that was just loaded. This copy may later 
be restored using the standalone version of the DDR program on the real 
machine, and it also provides a backup copy of the nucleus. 
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The sequence of coiiands and responses is: 

def cuu as 009 

CONS 009 DEFINED 

ipl CIS 

CMS. . .mm/dd/yy 

ddr 

ENTER: in 330 3330 sysres 

ENTER: out 181 2400 

ENTER: dump nuc 

DUMPING SYSRES 

END OF DUMP 

ENTER: 

END OF JOB 

R; T=0.21/2.63 15:04:04 



You created a backup copy of the CP nucleus. 



BDILDING A CMS NUCLEUS 

The same procedure can be used to update CMS modules. In this case, the 
order of search for updating is: 

191 A R/H 

293 B/A R/0 

190 C/A R/0 

393 D/A R/0 

To test CMS in a virtual machine before updating the real CMS system 
disk, adequate disk space must be available to contain a copy of the 
nucleus being tested (for example, on the virtual disk 390 as shown in 
Figure 27.) You can test modules on your 191 disk. Note that when 
disks are searched for a disk-resident command, the normal order of 
search is followed. Thus, if you have a module on your virtual 191 disk 
with the same filename as one on the system disk, the module on your 191 
disk is found first (assuming your 191 disk is accessed before your 
system disk) . Again, the userid MAINT can be used. 

I To build a new CMS nucleus, you must: 

I • Create a new CMS system disk. 

I • Generate a new CMS nucleus. 

I • Optionally, save the new CMS operating system. 
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CREATING A CMS SYSTEM DISK 

Use the following procedure to create a new CMS system disk: 

• IPL 190. 

• Issue the CMS FORMAT command to format the minidisk that you want to 
contain the new CMS operating system. 

• Issue the CMS FORMAT command with the RECCMP option to format the 
same minidisk with one or two cylinders less than the total number of 
cylinders on the disk (one on a 3330, two on a 2314 or 3340). The 
last cylinder (s) are used for the CMS nucleus. 

• Regenerate any MODULE file that uses an auxiliary directory. 
Auxiliary directories are described in the ^MZ^JZ^* ^jl^J^^IS 
l£2a£§.lS§ll§ Guide. Two modules distributed with the CMS system, 
ASSEMBLE and CPEREP, use an auxiliary directory. Regenerate ASSEMBLE 
by invoking the ASMGEND EXEC procedure and regenerate CPEREP by 
invoking CMSGEND. Both of these procedures are described earlier in 
Part 6. IBM Program Products may also use an auxiliary directory. 

• Generate a new CMS nucleus using the sequence of commands described 
in the following section. 



GENERATING THE CMS NUCLEUS 

Use the following commands to generate a new CMS nucleus: 

• Load the CMS system disk if you have not already ' loaded it. The 
address is usually 190. 

ipl cuu 

• Access the disk that contains the CMS text files that are used to 
create the nucleus. 

access cuu a 

• Spool your punch to your reader. 

spool d to * 

• Punch a copy of the CMS nucleus. 

vmfload cmsload dms 

• Load the CMS nucleus into storage. A load map is produced and spooled 
to the virtual printer. 

ipl c 

After the IPL sequence, the following questions are asked. 

DMSINI606R SYSTEM DISK ADDRESS = CUU 

Enter the device address (cuu) of the system disk (S-disk) . 
On this disk CMS expects to find all CMS system information 
and programs not contained within the CMS nucleus, such as 
the disk -resident command modules. If the CMS nucleus is 
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written on this disk, then cuu is also the IPL device 
address. 

If you enter an invalid device address, the message 

DMSINI079E INVALID DEVICE ADDBESS - BEENTEB 

is issued. Message EHSINI606B is reissued so that you can 
enter a valid device address. 

If you press the carrier return without entering a device 
address, X'190' is assumed to be the system disk address. 

Once the system disk address entered is accepted, message 
DMSINI615B is issued. 

DMSIMieiSB Y-DISK ADDRESS = CUU 

Enter the device address (cuu) of the system disk extension 
(Y-disk) . On this disk CMS expects to find all CMS system 
information and programs not contained within the CMS 
nucleus and not on the S-disk. If the CMS nucleus is written 
on the Y-disk, then cuu is also the IPL device address. 

If you enter an invalid device address, the message: 

DMSIHI079E INVALID DEVICE ADDRESS - REENTER 

is issued. Message DMSINI615R is reissued so that you can 
enter a valid device address. 

If you press the carrier return without entering a device 
address, X'19E' is assumed to be the address of the system 
disk extension. 

Note: If you do not want to have a Y-disk, do not attach the 
device that was specified (or defaulted to) as the Y-disk 
address. 

Once the address entered for the system disk extension is 
accepted, message DMSINI607R is issued. 

DMSINI607R REWRITE THE NUCLEUS? (YES | NO) 

If you enter "yes", a copy of the CMS nucleus is written 

onto the disk indicated in the response to message 

DMSINI608R. If you enter "no", the CMS nucleus is not 
written to disk. 

If you enter neither "yes" nor "no," the message 

DMSINI081E INVALID REPLY - ANSWER "YES" OR "NO" 

is issued. Message DMSINI607R is reissued so that you can 
enter a valid response. 

If you enter "no", the remaining questions in generating a 
new CMS nucleus eire skipped and control is passed to the CMS 
initialization routine. 

If you enter "yes", message DMSINI608R is issued. 
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DMSimeOSR IPL DEVICE ADDRESS = cuu 

Enter the address of the device (cuu) on which the CMS 

nucleus is to be written. If the system disk and the IPL 

device are to be the saMe. you need only press the carrier 
return. 

If you enter an invalid device address, the message 

DBSINI079E INVALID DEVICE ADDRESS - REENTER 

is issued. Message DMSINI608R is reissued so that you can 
enter a valid device address. 

If the IPL device you designated is not currently defined, 
is not in read/write status, or is an unsupported device 
type, the message 

DMSINI082E IPL DEVICE ERROR - REENTER 

is issued. Message DMSINI608R is then reissued. At this 
time, you may enter CP mode by pressing the Attention key 
(or eguivalent) , then determine the status of the device you 
designated by entering the CP command 

QUERY VIRTUAL CUU 

and take the corrective action necessary to define the 

device for your virtual machine or to access it in 

read/write status. You may reenter CMS by issuing the CP 
command 

BEGIN 

Then you must reenter the device address. Once the device 
address is accepted, message DMSINI609R is issued. 

DMSINI609R NUCLEUS CYL ADDRESS = nnn 

Enter the cylinder number (nnn) , for the device entered in 
response to message DMSINI508R, where the CMS nucleus is to 
be written. The number (nnn) must be between 001 and m-1 
(where m eguals the number of cylinders on the disk, the 
cylinders being numbered from to m-1). The number, nnn, 
must be entered in decimal. If the system disk and the IPL 
device are the same, follow the directions for issuing the 
FORMAT command in the "Creating a CMS System Disk" section. 

If you do not enter a valid decimal cylinder number, the 
message 

DMSINI080E INVALID CYLINDER NUMBER - REENTER 

is issued. Message DMSINI609R is reissued and you may enter 
a valid cylinder number. 

If the cylinder specified is not greater than the number of 
cylinders already in use on the device (as indicated in the 
Master File Directory, then the message 

DMSINI083E NUCLEUS HILL OVERLAY FILES - RECOMPUTE 

is issued. You may respond with a larger cylinder number, 
or IPL CMS and format the specified IPL device with the 
RECOMP option. 
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Once the nucleus cylinder address is accepted, message 
DHSINI610B is issued. 

DI1SINI610R ALSO IPL CYLINDER 0? (YES|NO) 

The initial IPL text is always written on the same cylinder 
as the CMS nucleus (the cylinder designated in response to 
message DHSIBI609H) . The initial IPL text is a bootstrap 
program which reads the nucleus from the designated 
cylinder. If it is not also written on cylinder 0, then you 
must enter the cylinder number when subsequent IPL commands 
are issued for the system being generated. See the IPL 
command description in the VM/370: Command Lan^ua^e Guide 
i.9L General Users. Your response has the following meaning: 

yes Initial IPL text is written on cylinder as well as on 
the cylinder designated in response to message 
DMSINI609R. 

no Initial IPL text is written only on the cylinder 
designated in response to message DMSINI609R. 

If you do not enter "yes" or "no," the message 

DMSINI081E INVALID REPLY - ANSWER "YES" OB "NO" 

is issued. Message DMSINI610R is reissued so that you can 
enter a valid response. 

If your response is valid, message DMSINI611R is issued. 

DMSINI611R VERSION IDENTIFICATION = 

Enter up to 32 bytes of information, including blanks, to 
specifically identify the version and level of CMS; this 
information is printed each time you IPL the CMS system now 
being generated. The default identification (specified by a 
carrier return) is: 

CMS VERSION n.n - mm/dd/yy 

where n.n is the version and level of CMS, and mm/dd/yy is 
the month, day and year the CMS nucleus was created. 

DMSINI612R INSTALLATION HEADING = 

Enter up to 64 bytes of information, including blanks, to 

serve an installation standard heading at the beginning of 

each output file. The default heading (specified by a 
carrier return) is: 

CONVERSATIONAL MONITOR SYSTEM 

The nucleus is then written on the specified disk cylinder and the 
version identification is displayed, indicating that the CMS system is 
loaded successfully and is ready to accept CMS commands. 

At this point, you may save the CMS system. See the section on "Saved 
Systems." If you wish to save a copy of the nucleus as a disk file, 
which can be punched to the virtual punch later, you should issue SPOOL 
C HOLD so that a copy of the nucleus remains in the card reader after it 
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is loaded. Also, if you wish to save a copy of the load map as a disk 
file, spool your printer to yourself. 

The following is an example of the commands you issue to load the new 
CMS nucleus ! 

• Direct the nucleus to your reader. 

spool d to * 
R; 

• Punch the nucleus. 

vmfload cmsload dms 

SYSTEM LOAD DECK COMPLETE 

PDH FILE 0355 TO MAINT COPY 01 NOHOLD 

R • 

• Hold the file in the reader so that it is not lost after the IPL 
completes. 

spool c hold 

R; 

• Spool the printer to your reader. 

spool e to * 
R; 

• IPL the card reader, thereby creating the load map. 

ipl c 

DMSINI696R SYSTEM DISK ADDRESS = 130 

DMSim615E Y-DISK ADDRESS = 19e 

DMSINI607R REWRITE NUCLEUS ? yes 

DMSimeOSR IPL DEVICE ADDRESS = 191 

DMSINI609R NUCLEUS CYL ADDRESS = 9 

DMSINI610R ALSO IPL CYLINDER ? yes 

DMSINI611R VERSION IDENTIFICATION = 

DMSI8I612R INSTALLATION HEADING = 
CMS VERSION 2.0 - 03/29/74 16:47 

R; 

spool rdr nohold 

close prt 

close rdr 

PRT FILE 0342 TO MAINT COPY 01 NOHOLD 

• Read a copy of the CMS nucleus to disk. 

read cmsnuc nucleus a1 

R; 

• Read a copy of the CMS load map to disk. 

read cmsnuc loadmap a1 
RECORD LENGTH IS •132» BYTES. 

R; 

You now have two CMS files on this 191 disk: CMSNUC NUCLEUS, which 
contains the CMS nucleus created above, and CMSNUC LOADMAP, the load map 
for this nucleus. This procedure is useful when you want to punch the 
file containing the particular nucleus created to a virtual card reader 
at some later time. 
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To regenerate a nucleus which exists as a disk file (CMSNOC HUCLEOSr 
for example) , issue the following commands: 

spool pun to ♦ 

punch cmsnuc nucleus a1 (noheader) 

ipl 00c 

You may then answer the questions previously described. 

If you wish, you can test a new CMS nucleus by writing the test 
nucleus on device 390. To do this, respond as follows to these two 
questions: 

DMSINI606R SYSTEM DISK ADDRESS = 190 
DMSINI608R IPL DEVICE ADDRESS = 390 

By specifying different devices as your S-disk and IPL device, you can 
test the updated CMS by loading 390 before putting the updated CMS 
nucleus into general use. 

CMS modules can be tested on your virtual 191 before they are placed 
on the system disk. 

Once the update is successfully tested, you can move it from your 191 
to your 193 for permanent retention. 



SAVING THE CMS SYSTEM 

I The DMKSNT module must have been configured when CP was generated. If 
I you coded a NAMESYS macro for CMS, you have an entry in the system name 
I table and can save the CMS system by entering the SAVESYS command as the 
first command after IPL. Enter the command: 

SAVESYS name 

as the first command after the IPL command. Enter the SAVESYS command 

when the CMS version identification is displayed. The "nane" specified 

on the SAVESYS command is the name assigned to the saved system via the 
HAMESYS macro. 

When you IPL a saved CMS system, CMS operates as if an IPL of a 
specific device occurred, with the single exception that the directory 
for the system disk is part of the nucleus. 



CMS SOURCE PROGRAMS 

To format a minidisk to contain the CMS source programs, IPL the CMS 
system disk and issue the CHS FORMAT command. This minidisk must be at 
I least 120 cylinders for a 231U (or 2319) , 60 cylinders for a 3330 disk, 
I or 160 cylinders for a 3340 disk. Then, you should have the CMS source 
tape mounted and attached to the virtual machine, and issue the 
following commands to load the source programs onto the CMS disk: 

TAPE FSF 

TAPE LOAD (EOF 2) 
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CREATING CMS DISK-RESIDENT MODULES 



CMSGEND is a procedure provided to create CMS disk-resident coimand 
■odules from CMS TEXT files. The procedure is invoked by specifying: 



r T 

CMSGEND filename {CTLCMS | 
iCTLALL I 
INOCLEARI 
I MAP I 



JNUINV 

L 



where filename is the name of the module to be generated. 

CMSGEND creates a history of modules. Any existing file with the 
identification of 'filename MODULE A2' is renamed 'filename MODOLD AT. 
An existing file of 'filename MODOLD A1' is erased. The CMSGEND EXEC 
procedure displays the "CURRENT STATUS" of these modules. 

CMSGEND then loads the TEXT files that comprise the module 
'filename'. A "LOADING" message is displayed, and 'filename MODULE A2' 
is generated. The CMSGEND EXEC procedure then displays the results of 
the procedure, including the identification of the command and the text 
files used to generate it. 

You must access the S-disk as your read/write A-disk, and have all 
pertinent TEXT files available before invoking the CMSGEND EXEC 
procedure. For example, to replace an ACCESS module, enter: 

cmsgend access 



*** CURRENT STATUS: 

FILE 'ACCESS MODULE A2' DOES NOT EXIST 
FILE 'ACCESS MODOLD A1' DOES NOT EXIST 
*** LOADING: 
ACCESS SD OOEOOO 
READFST SD 00EAC8 

INVALID CARD - V0142DMS ELIMINATES WRITE BACK OF MED TO FIND OUT IF 

DISK IS R/0 

4/18/74 14:47 
4/21/74 8:44 
4/22/74 10:15 
4/18/74 17:29 



INVALID 


CARD - * 


DMSACM 


V0142DMS 


D1 


CMS191 


INVALID 


CARD - * 


CMSLIB 


MACLIB 


D1 


CMS 191 


INVALID 


CARD - * 


OSMACRO 


MACLIB 


S2 


CMS190 


INVALID 


CARD - * 


DMSACM 


ASSEMBLE 


CI 


SOURCE 


DMSACM 


SD OOEDBO 










READMFD 


OOEDBO 










DMSALU 


SD 00F0A8 










RELUFD 


00F0A8 










£ND$RELl 


I 00F1F8 











*** RESULTS: 

' ACCESS MODULE A2' CREATED FROM TEXT DECK 

WITH ATTRIBUTES TRANS NOMAP 

R; 



( S ) DMSACC DMSACF DMSACM DMSALU 
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USING THE ZAP SERVICE P BOG RAM TO UPDATE CMS MODULE, LO ADLIB, OR TXT LIB 

ZAP is a CMS coiiand that Modifies or dumps MODULE, LOADLIB, or TXTLIB 
files. It is for use by system support personnel only. 

Input control records control ZAP processing. They can be submitted 
either from the terminal or from a disk file. Using the VER and REP 
control records, you can verify and replace data or instructions in a 
control section (CSECT) . Using the DUMP control record, you can dump 
all or part of a CSECT, or an entire member of a LOADLIB or TXTLIB file, 
or an entire module of a MODULE file. 



The format of the ZAP command is: 



ZAP 



(module ) 

< LOADIIB> [libname* 

(txtlib ) 



.. Iibname3 ][ (option. ..[)] ] 

options: 

r T r T 

I TERM I I PRIM I 

IINPUT filenamel INOPRINTI 

L J L J 



where: 



MODULE 

LOADLIB 

TXTLIB 



indicates the type of file that is to be modified or dumped. 



libname is the library name containing the member to be modified or 
dumped. You can specify one to three library names. The 
libname is valid only for LOADLIB and TXTLIB files. 

O£tions 



TERM 



! PRINT ! 
INOPRINTI 



indicates that input to the ZAP service program is 
submitted through the terminal. If you specify TERM, the 
prompting message ENTER: is issued, and you can then 
enter input control records up to 80 characters long. 

If you specify PRINT with TERM, all output prints on the 
printer, but only error messages display at the 
terminal. 

If you specify NOPRINT with TERM, nothing prints on the 
printer. All output except control records displays at 
the terminal. 



INPUT filename 



r T 

I IMMl I 

INOPRINTI 

L J 

specifies 
filename, 
must be a 



that input is submitted from a disk file. 
This file must have a filetype of ZAP, and 
fixed 80— byte seguential file residing on any 



accessible device. 
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If you specify PRINT with INPUT filename, all output 
produced by the ZAP service program prints on the 
printer. In addition, commands and control records in 
error and error messages display at the terminal. 

If you specify NOPRINT with INPUT filename, nothing 
prints on the printer. All output displays at the 
terminal. 



The following table shows the resulting output of valid option 
combinations : 



OPTIONS I 



INPUT 



TERM 



PRINT 



NOPRINT 



Commands and control 
records in error and 
error messages on the 
terminal. Everything 
to printer. 

Only error messages on 
the terminal. 
Everything on the 
printer. 



Everything on the 
terminal. Nothing 
on the printer. 



Everything except 
control records 
on the terminal. 
Nothing on the 
printer. 



I ZAP INPUT CONTROL RECORDS 



Seven types of ZAP control records exist: 
VERIFY, REP, comment, and END. 



NAME, DUMP, EASE, VER or 



ZAP control records are free form and need not start in position one 
of the record but the ZAP program can accept only 80 characters of data 
for each control record. Separate all information by one or more 
blanks. All address fields including disp (displacement) fields in VER 
and REP control records must contain an even number of hexadecimal 
digits, to a maximum of six digits (OD, 02C8, 014318) . Data fields in 
VER and REP control records must also contain an even number of 
hexadecimal digits, but are not limited to six digits. 

If you wish, you -may separate the data anywhere by commas (for 
example, 83256482 or 8325,6482). The commas have no effect on the 
operation. 

The program sets the NOGO switch on if a control record is found to 
be in error. A file cannot be modified once the NOGO switch is turned 
on. The next valid NAME record turns the NOGO switch off. This means 
that if the control record is the NAME record, all succeeding records 
are ignored until the next NAME, DUMP, or END record. For any other 
error, only REP control records that follow are ignored. 



DUMP Control Record 



The DUMP control record resets the NOGO switch off. The DUMP control 
record must not immediately precede a BASE, VER, or REP control record. 
A NAME control record must precede the BASE, VER, and REP control 
records (if any) that follow a DUMP control record. 
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The DUMP control record allows you to dump a portion or all of a 
specified control section, or the complete member or module. The format 
of the output of the dump is hexadecimal with an EBCDIC translation of 
the hexadecimal data. 

The DOMP control record is optional. The format of the DUMP control 
record is: 



DUMP r membername ) jcsectname [startaddress [ endaddress ] ] | 
( modulename j (ALL I 



where : 

membername is the name of the member to be dumped, or the member 
that contains the CSECT(s) to be dumped. This member 
must be found in one of the libraries specified in the 
ZAP command line. However, if the library is a CMS 
TXTLIB, its directory does not contain member names. 
Therefore, the program ignores the member name (although 
you must specify it) , and the program searches for the 
csectname (which you must specify) . 

modulename is the name of the module to be dumped, or the module 
that contains the CSECT (s) to be dumped. If you specify 
a module that has no loader table, the program dumps the 
entire module. 

csectname is the name of the control section that is to be dumped. 
If you do not specify csectname, the program dumps only 
the first CSECT. 

The csectname is required for CMS TXTLIBs, optional for 
OS TXTLIBs, LOADLIBs, and MODULE files. (See the 
discussion of csectname under "Name Control Record.") 

You must not specify csectname for a module created with 
the NOMAP option. 

ALL specifies to the program to dump all CSECTs within the 

specified member or module. You can specify ALL for 
MODULE files, LOADLIBs, and OS TEXTLIBs, but not for CMS 
TXTLIBS. If you wish to dump all the CSECTs in a member 
of a CMS TXTLIB, you must issue a separate DUMP control 
record for each CSECT. 

startaddress is the location within the specified CSECT where the dump 
is to begin. This must be two, four, or six hexadecimal 
digits. 

The start address is the displacement from the beginning 
of the CSECT. For example, if you wish to start dumping 
at address 08 in a CSECT that begins at location UOO, you 
specify start address or 08, not 0U08. 
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endaddress is the last address to be dumped. This must be t¥o, 
four, or six hexadecimal digits. If you specify no 
address, the program dumps the rest of the CSECT. Note 
that start and end addresses apply only when you specify 
a csectname. 

If the file to be dumped contains undefined areas (such 
as a DS in a TXTLIB member) , the hexadecimal portion of 
the dump contains blanks to indicate that the 
corresponding positions are undefined. 

I HAME Control Record 



The MAME control record specifies the member or module and CSECT that 
contain the data to be verified or replaced by the ZAP operation. The 
format of the MAME control record is: 



NAME j membername ) [csectname] 
I modulename f 



where: 



{: 



■ embernamel^ 
odulename j 

is the member or module that you want to be searched for the 
desired CSECT. 



csectname is the name of the desired control section. You must 
specify csectname if the CSECT you wish to modify is in a 
CBS TXTLIB (that is, TXTLIB created by the TXTLIB command 
from CMS TEXT decks that do not have a NAME card following 
the END card). 

The directory of a CMS TXTLIB contains only CSECT names and 
no member names. The CSECT name specified in the NAME 
record is compared with CSECT names in the directory. If a 
CSECT match is found and no member name match is found, the 
member selected is the one that contains the CSECT name. 

The csectname is optional if the CSECT you wish to modify is 
a LOADLIB or an OS TXTLIB (that is, a TXTLIB created by the 
TXTLIB command from CMS TEXT decks that have a NAME card 
after the END card) . The dictionaries of the specified 
libraries are searched for the member name and the member is 
then searched for the CSECT name, if you specified one. If 
you do not specify csectname for a LOADLIB or an OS TXTLIB, 
the program uses the first control section. 

The csectname is optional for a MODULE file. The module 
named in the NAME control record is located and, if you 
specified csectname, the first record is read to determine 
the number of records in the module and the availability of 
a loader table, which the program can then search for the 
csectname. 

If you do not specify csectname, the program uses the 
beginning location of the module. You are not allowed to 
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I specify csectnaae if the module was created with the NOMAP 

I option. 

I The NAME control record must precede the EASE, VER, and REP 

I control records. If it does not, the program sets the NOGO 

I switch on. 



I SASE Control Record 

I The BASE control record adjusts displacement values for subsequent VER 

I or REP control records for a CSECT whose starting address is not 

I location zero in an assembly listing. The format of the BASE control 

I record is: 



I 1 

I i 

I BASE address I 

I I 

I I 



I w h er € : 

I address is the starting address of the CSECT. The address must be 

I two, four, or six hexadecimal digits. 

I For example, for a CSECT starting at location UOO, you would 

I specify the BASE 0400 in the BASE control record. If a 

I subsequent VER card requests verification of location 0408, 

I the BASE of 0400 is subtracted from 0408, and the program 

I verifies location 08 in the CSECT. This example applies if 

I you specify TXTLIB, LOADLIB, or MODULE and the module map is 

I present. 

I However, if no module map is present for a MODULE file (that 

I is, the module was generated with the NOMAP option) , then all 

I operations are performed as if the BASE address is location 0. 

j For example, if you specify a BASE of 400 and the address you 

I wish to inspect or modify is 408, then you must specify 08 and 

I not 408 in REP and VER control records. The address in this 

I case is from the start of the module. If you do not specify 

I csectname in the NAME control record, you cannot specify any 

I BASE value other than 00. 

I The BASE control record is optional. See the discussion under 

I "VER or VERIFY Control Record." If specified, the BASE 

I control record must follow the NAME record, but it need not 

I follow the NAME record immediately. For example, you could 

I have the following sequence of control records: NAME, VER, 

I REP, BASE, VER, REP. 



I III 0£ VERIFY Control Record 

I The VER contrjDl record requests verification of instructions or data 

I within a CSECT. If the verification fails, the program does not perform 

I a subsequent REP operation until it encounters another NAME control 
I record. 
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I The VER control record is optional. More than one VER record can 
I follow a single NAME record. 

I The format of the VER control record is: 



( VERIFY \ disp data 



I I t VER / I 

I I i 

I I J 

I where : 

! disp is the hexadecimal displacement of the data to be inspected 

I from the start of the CSECT, if you did not submit a BASE 

I control record for this CSECT. If you did submit a BASE 

I control record, then disp is the actual location of the data. 

I The disp must be two, four, or six hexadecimal digits. This 

I displacement does not have to be aligned on a fullword 

I boundary. If this displacement value is outside the limits of 

I the CSECT specified by the preceding NAME control record, the 

I VERIFY control record is rejected. 

I data is the data against which the data in the CSECT is to be 

I compared. This must be an even number of hexadecimal digits. 

I For example, if the location you wish to verify is 3CC, and 

I the CSECT begins at location 2B0, you can either issue: 

I BASE 02B0 

I VER 03CC data 

I or you can omit the BASE control record, subtract the CSECT 

I start address from the address of the data, and issue: 

I VER one data 

I This also applies to the disp operand of the REP control 

I record. 



I IIJP Control Record 

I The REP control record modifies instructions or data at the specified 

I location within the CSECT that you specified in a preceding NAME control 

I record. The data specified in the REP control record replaces the data 

I at the CSECT location specified by the disp operand. This replacement 

I is on a "one-for-one" basis; that is, one byte of data defined in the 

I control record replaces one byte of data at the location that you 

I specified. If the replacement fails, the program does not perform 

I additional REP operations until it encounters another NAME control 

I record. 

I The REP control record is optional. More than one REP record can 
I follow a single NAME record. 



Part 6: Updating VM/370 327 



The format of the REP control record is: 



, , 

I I 

I I REP disp data 

I I 

I I 



I wheES • 

I disp is the hexadecimal displacement of the data to be replaced 

I from the start of the CSECT, if you did not submit a BASE 

I control record for this CSECT. If you did submit a BASE 

I control record, then disp is the actual location of the data. 

I The disp must be two, four, or six hexadecimal digits. This 

I displacement need not address a fullword boundary. If this 

I displacement value is outside the limits of the CSECT being 

I modified, the program does not perform the replacement 

I operation. 

I data is the data that is to replace the data in the CSECT. This 

I must be an even number of hexadecimal digits. 

I Note; Although you do not have to verify a location before replacing 

I data, you should do so to make sure that the data being changed is what 

I you expect it to be. 



I Comment Control Record 

I The ZAP program ignores comment control records. If the PRINT option is 

I in effect, the program prints the comments. The format of a comment 

I record is: 



I 

I * comment 



I You must follow the asterisk with at least one blank, 



I END Control Record 

I The END control record ends ZAP processing. The END record is required 

I and must be the last control record. The format of the END control 

I record is: 



I i I 

I I END I 

I I I 

I 1 1 
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I SPECIAL CONSIDERATIONS FOR USING THE ZAP SERVICE PROGRAM 

Before you use the ZAP command against MODULE files, you can use the 
MODMAP command to determine whether a module map exists and what it 
contains. 

When a ZAP input file has more than one pair of VER and REP control 
records and a VER control record (other than the first) fails, you must 
remove the records prior to the failing record and correct the error 
before you issue the ZAP command again. Otherwise, the file being 
modified returns to its original status. 

If you issue REP control record against a file that contains an 

undefined area (for example, a Define Storage area) within the REP data 

field and do not issue a VER control record prior to the REP control 

record, the bytes prior to the undefined area, if any, are modified and 

all the bytes after the undefined area are not modified. The program 
prints warning message DMSZAP2U8W. 



I MIIiSIM AN RSCS NUCLEUS 

The same procedure used to update CP and CMS can be used to update 
RSCS. However, unlike CP and CMS, RSCS can test the system that is 
built; it does not need to test a duplicate copy of the system that is 
built. In this case, the order of search for updating is: 

195 A 
194 B/A 

Again, the MAINT virtual machine can be used to do the updating. 

To build a new RSCS nucleus you must create a new RSCS system disk 
and generate a new RSCS nucleus. 



! CREATING AN RSCS SYSTEM DISK 

Use the following procedure to create a new RSCS system disk: 

• Log on as MAINT. 

• IPL 190. 

• Link to the minidisk that you want to contain the new RSCS nucleus as 
195 in write status and access it as your A-disk. 

• Issue the CMS FORMAT command to format that minidisk. 

• Issue the CMS FORMAT command with the RECOMP option to format the 
same minidisk with one or two cylinders less than the total number of 
cylinders on the disk (one less on a 3330, two less on a 2314 or 
3340). The last cylinders are used for the RSCS nucleus. 

• If you wish to change the RSCS configuration, recreate the AXSLINKS, 
LAXLINES, and TAGQUEUE COPY files and create a new DMTLOC macro 
library. See "Part 3: Generating VM/370 (CP, CMS, and RSCS)." 

• Generate a new RSCS nucleus using the commands described in the 
following section. 
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I GENERATING THE RSCS NUCLEUS 

• Load the BSCS files onto the CP system disk (the 194 Binidisk 
belonging to MAINT) if they are not already there. 

• Access the MAINT 194 disk as an extension of the RSCS system disk, 
access 194 b/a 

Note: If you want to apply your own updates, they should be on the 
294 disk. Then disk access should be: 

access 294 b/a 
access 194 c/a 

• Assemble the RSCS configuration table module, DMTSYS, using the 
VMFASM EXEC procedure. The control file DMTR20 identifies DMTLOC as 
the macro library. 

vmfasm dmtsys dmtr20 

If an error occurs due to an incorrectly coded macro, correct the 
macro and restart by generating a new DMTLOC macro library. 

Note: If you do not have enough disk space to assemble, acquire 
additional T-disk space. 

• Close and clear the punch and reader. Spool the punch to your 
virtual card reader. Use the VMFLOAD EXEC procedure to punch the 
RSCS nucleus. The loadlist EXEC, DMTLOAD, contains the filenames of 
all the RSCS TEXT modules. 

close pun 

R; 

close rdr 

R; 

purge rdr all 

R; 

purge pun all 

R; 

spool pun to * 

R; 

vmfload dmtload dmtr20 
SYSTEM LOAD DECK COMPLETE 
PUN FILE spoolid TO userid 
R; 

• Copy the RSCS Supervisor TEXT decks, DMTAXS and DMTLAX, from the 
MAINT 194 disk to your RSCS system disk. 

copyfile dmtaxs text b1 = = a1 (replace olddate 

R; 

copyfile dmtlax text b1 = = a1 (replace olddate 

R; 
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Copy the required line driver TEXT decks, DMTMPT and/or DMTSML, from 
the MAINT 194 disk to the RSCS system disk. The MAINT 191 disk can 
now be released and detached. 

R; 

copyfile dmtsml text b1 = = a1 (replace olddate 

R; 

release 194 

R; 

detach 194 

DEV 194 DETACHED 

R; 

IPL your card reader which contains the ESCS nucleus that was punched 
in Step 8. A series of prompting messages requests information 

nucleus. Answer them as shown. 

ipl c 

DMTIHI407R REWRITE THE NUCLEUS ? yes 

DMTIMI408R IPL DEVICE ADDRESS = 195 

DMTINI409R NUCLEUS CYL ADDRESS = 003 (or, 004 for 3330) 

DMTIHI410R ALSO IPL CYLINDER ? yes 

The message 

DMTAXS103E FILE 'spoolid* REJECTED -- INVALID DESTINATION 
ADDRESS 

is issued. It indicates that the RSCS nucleus file was purged from 
the card reader. 

The message shown in line 1 of the following example indicates 
completion of the writing of the RSCS nucleus on the specified disk. 
IPL the specified disk and start your RSCS operations as described in 
the VM/lIO: Remote Spooling Communications Subsystem (RSCS) User^s 
Guide. 

DMTREXOOOI RSCS (VER 1, LEV 1, mm/dd/yy) READY 

t 

CP 

logoff 

logon rscs 

ipl 191 
DHTREXCOOI RSCS (VER 1, LEV 1, mm/dd/yy) READY 
start newyork 



installation RSCS operation 



I Note: If you are logged on as MAINT, you IPL 195, but if you are 
I logged on as RSCS, you IPL 191 to IPL the RSCS system disk. 
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A. IBH Programs Executable under CMS 

B. Configuration Aid 

C. Representative Directory Entries 

D. CP/CMS Regeneration Requirements 

E. Hotational Conventions 

F. VM/370 Service Programs 

G. Compatibility of VM/370 with CP-67/CMS 

H. Creating a 3340 System Residence Volume from a Current 2314 
or 3330 System Residence Volume and the PLC Tape 
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Appendix A: IBM Programs Executable Under CMS 



ii!Z370 ASSEMBIEB 



A VM/370 Assembler is distributed as a part 
of the VI1/37Q s^steni and is required for 
installation and further support of the 
system. All necessary installation and 
support macros are provided in CMS 
libraries. 



The Conversational Mo 
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Figure 29 lists the IBM Program Products 
I that are executable under CMS. 



I To find the amount of storage required 
I to install a program product, refer to the 
I appropriate program product publication. 



I INSTALLED USER PROGRAMS 



A text-processing program is available: IBM 
Installed User Program (lUP) SCRIPT/370 
(IBM Program No. 5976-PAF) . SCRIPT/370 
creates formatted output from one or more 
CMS files, each of which contains text 
and/or SCRIPT control words. The SCRIPT 
files are created and modified at a 
terminal using the CMS Editor. 
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IBM 

Program Product 

OS Code 5 Go FORTRAN 

OS FORTRAN IV (G1) 

OS FORTRAN IV Library (Mod I) 

OS FORTRAN IV (H) Extended 

OS FORTRAN Library (Mod II) 

FORTRAN Interactive Debug 

OS/VS COBOL Compiler and 
Library 

OS/VS COBOL Library Only 

OS Full American National 
Standard COBOL Version 4 
Compiler and Library 

OS Full American National 
Standard COBOL Version 4 
Library 

OS COBOL Interactive Debug 

OS PL/I Optimizing Compiler 

VS BASIC Processor 

VS BASIC 

OS PL/I Resident Library 

OS PL/I Transient Library 

OS PL/I Optimizing Compiler 
and Libraries 

OS PL/I Checkout Compiler 

Planning Systems 

Generator/CMS (PSG/CMS) 
I 

Figure 29. IBM Program Products 



A time-sharing facility is available as 
an lUP: the McGill University System for 
Interactive Computing (MUSIC) , IBM Program 
No. 5796-AAT. MUSIC is a conversational 
time-sharing operating system that can 
execute in a virtual machine under VM/370. 



IBM 

Program 

Number 



5734-F01 
573U-F02 
573a-LM1 
573U-F03 
5734-LM3 
5734-F0 5 
5740-CB1 

57U0-LM1 
5734-CB2 

5734-LM2 

5734-CB4 
5734-PL1 
57a8-XX1 
5734-XX1 
5734-LM4 
5734-LM5 
5734-PL3 

5734-FL2 
57U8-XT1 
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Figure 30. Integrated Emulators that Execute Under VM/370 



I INTEGRATED EMULATORS 



Emulator-dependent programs (except for DOS 
emulation under OS or OS/VS) that execute 
on a particular System/370 equipped with 
the appropriate compatibility features can 
execute on that System/370 in DOS or OS 
virtual machines under VM/370. 

Figure 30 shows, by System/370 model 
number, which integrated emulators can 



execute under VM/370 and the compatibility 
feature numbers (#xxxx) that are required. 

No changes are required to the 
emulators, to DOS or OS, or to VM/370 
itself to allow emulator-dependent programs 
to execute in virtual machines. 

On the System/370 Model 158 only, the 
Virtual Machine Assist Feature cannot 
operate concurrently with the 7070/7074 
compatibility feature (Feature #7117). 
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Appendix B: Configuration Aid 



Appendix B shows the devices and control units that can be specified in 
a VM/370 system generation; they are grouped by use. It lists the 
control units* notes the sazisus nuisber that can be s'^ecified in the 
FEATDRE= operand of the RCTLDNIT macro, and tells whether or not the 
control units can operate on a shared subchannel. 

It shows the devices that can be attached to each control unit, and 
lists the operands that can be specified for each device in the RDEVICE 
macro. 

The control units and devices are placed in subgroups according to 

the ways they can be configured. For example, the chart of tape devices 

indicates that a 2401, 2402, or 2420 can be attached to a 2803 or 2804 
control unit. 



1 — __- __ — _ T 

1 1 RCTLUNIT 1 Shared 1 RDEVICE j 
1 1 1 c;ii Vi t ... - 1 


1 Type of 1 1 1 chan-j j j 
1 Device |CUT¥PE=| FEAT0RE= | nel |DEVTYPE=| Other Operands | 


ITape 1 3803 | 16-DBVICE| yes | 3420 |M0DEL=3, 4, 5, 6, 7 or 8| 
1 Devices | | | | |FEAT0RE=7-TRACK,D0ALDENS| 


1 System | 1052 | — | — | 1052 | — | 


1 1 3210 1 — 1 _ 1 3210 1 — 1 


1 1 3215 1 — 1 — 1 3215 1 — 1 


1 1 2150 1 — 1 — 1 2150 1 — 1 


1 1 3066 1 — 1 — 1 3066 | — | 


1 1 3158 1 — 1 — 1 3158 1 — 1 


1 Trans- | 2701 | — | — | 2701 |ADAPTER=BSCA, IBM1, or | 
1 mission | | III TELE2 j 


1 Units 1 2702 | 16-DEVICE| — | 2702* | ADAPTER=BSCA, IBMI, or j 
1 II III TELE2 1 
1 II II |SETADDR=0, 1, 2, or 3 | 


1 1 2703 1176-DEVICEI — | 2703* | ADAPTER=BSCA, IBMI, or | 
1 II III TELE2 1 


1 1 3704 1 16-DEVICEI — | 3704 | ADAPTER=BSCA , IBMI, j 
1 1 3705 1256-DEVICEI | 3705 | TELE2, TYPEI, or TYPE2 | 
1 II II |M0DEL=1, 2, 3, 4, 5, | 
1 1 1 1 1 1 6, 7, or 8 1 
1 It II |SETADDR=0, 1, 2, or 3 | 
1 II II |CPTYPE=EP, NCP, or PEP | 
1 II II |CPNAME=ncpname | 
1 II II |MAXDIAL=nn | 
1 II II |BASEADD=cuu j 


I^Specify 2702 or 2703 as the device type for CPT-TWX (33/35), 2741, | 
1 1050, and 3767 (operating as a 2741) terminals. j 
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1 1 RCTLUHIT ISharedl RDEVICE | 


1 Type of 1 1 1 chan-| | I 
1 Device |CUTYPE=| FEATURE= | nel |DEVTYPE=| Other Operands | 


ITrans- | ICA | 16-DEVICEI — | ICA | ADAPTER=BSCA, IBM1, or | 
1 Mission II III TELE2 j 


1 Units 1 2955 | — j _ | 2955 | — | 
1 (cont) 1 1 1 1 1 1 


IDisplay 1 2848 | 32-DEVICE| yes | 2260 | — | 
1 Devices | j | | 1052 | I 


1 1 2845 1 — 1 yes 1 2265 | ~ | 


1 1 2250 1 — 1 — 1 2250 | — j 


1 1 3272 1 32-DEVICEI yes | 3277 |FEATDRE=OPRDR | 
1 II II 3284 1 1 
1 II II 3286 1 1 


[Remote | 2701 | — | — | 2701 |ADDRESS=cuu (line | 
1 3270 II III address) | 
1 Display II II |ADAPTER=BSCA | 
1 Devices | | | | | CLUSTER=label { 


1 1 2703 1 — 1 — 1 2703 |ADDRESS=cuu (line | 
1 11 III address) | 
1 II 11 |ADAPTER=BSCA t 
1 II II |CLUSTER=label | 


1 1 ICA 1 — 1 — 1 ICA |ADDRESS=cuu (line | 
t II III address) | 
1 II II |ADAPTER=BSCA | 
1 II II |CLUSTER=label | 


1 1 3704 1 — 1 — 1 3704 |ADDRESS=cuu (line | 
1 1 3705 1 1 1 3705 | address) | 
1 II II |ADAPTER=BSCA | 
1 1 j 11 |CPTYPE=EP 1 
1 II II |BASEADD=cuu | 
1 II II |CLUSTER=label | 


IDirect | 2841 | — | yes | 2311 | I 
1 Access II II 2321 | 1 
1 Storage | j | | 2303 | I 


1 1 2314 1 — 1 yes 1 2314 | I 
1 1 2319 1 1 1 2319 1 1 
1 1 IFA III! 1 


1 1 3830 1 32-DEVICEI | 3330 |M0DEL=1, 2, or 11 | 

1 1 3345 1 16 DEVICEI | 3333 |M0DEL-1 or 11 | 
1 1 ISC 1 16-DEVICEI yes | | I 


1 1 3830 1 32-DEVICEI | 3340 | I 
1 1 3345 1 16-DEVICEI | | 1 
1 1 ISC 1 64-DEVICEI | | I 
1 1 IFA 1 1 t 1 1 


1 1 2820 1 — 1 yes | 2301 | I 
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r - - - ■■■• " ■- -- - - ■■ ■ ' ■ '■ ■ ' '1 

j 1 RCTLUNIT ISharedl RDEVICE | 
1 1 .... , 1 <?n h 1 1 


1 Type of 1 1 1 chan-l | I 
1 Device |CUTYPE=| FEATURE= | nel |DEVTYPE=| Other Operands | 


IDirect 1 2835 | — | — | 2305 |M0DEL=1 or 2 | 
i Access 1 1 1 1 1 t 
1 Storage III!! 1 
1 Devices 1 1 1 1 1 1 
1 (cont) 1 1 i 1 1 1 


ITape 1 2803 | 16-DEVICEI yes | 2401 |M0DEL=1, 2, 3, 4, 5, 6, | 
i Devices | 2804 | 16-DEVICE| ' | | or 8 | 
1 II It |FEATDRE=?-TRACK, | 
1 II III DUALDENS | 
1 II II 2402 |M0DEL=1, 2, 3, 4, 5 or 6| 
1 II 11 |FEATDRE=7-TRACK, CONV, | 
1 II III DUALDENS | 
1 11 II 2420 |M0DEL=5 or 7 | 


1 1 2403 1 16-DEVICEI yes | 2403 |M0DEL=1, 2, 3, 4, 5 or 6| 
1 1 2404 1 1 1 2404 | FEATURE=7-TRACK, CONV, | 
i 11 III DUALDENS | 


1 1 2415 1 — 1 yes | 2415 |M0DEL=1, 2, 3, 4, 5 or 6| 
1 II II |FEATURE=7-TRACK, CONV | 


1 1 3411 1 — 1 yes | 3410 |M0DEL=1, 2, or 3 | 
1 1 1 1 1 3411 |FEATURE=7-TRACK, | 
1 II ill DUALDENS | 


1 1 3803 1 16-DEVICEI yes | 3420 |M0DEL=3, 4, 5, 6, 7 or 8| 
1 II II |FEATDRE=7-TRACK, | 
1 II III DUALDENS | 


lUnit 1 2821 1 — 1 — 1 1403 | CLASS= (class[ , class. ..]) 1 
1 Record | | | | |FEATURE=UNVCHSET | 
1 Output II II 2540P |CLASS= (class[ , class... ]) 1 


1 1 1442 1 — 1 — 1 1442P 1 1 
1 1 1443 1 1 1 1443 !CLASS=(class[ , class... ]) 1 


1 1 3811 1 — 1 — 1 3211 |CLASS=(class[ , class... ]) 1 


1 1 2826 1 — 1 — 1 1018 1 1 


1 1 2520 1 — 1 — 1 2520P |CLASS= (class, [ class. ..]) j 


1 1 3505 1 — 1 — 1 3525 |CLASS= (class, [ class. ..]) | 


lUnit 1 2821 1 — 1 — 1 2540R | | 


1 Input 1 2520 1 — 1 — 1 2520R | | 


1 1 3505 1 — 1 _ 1 3505 | | 


1 1 1442 1 — 1 — 1 1442R | | 


1 1 2495 1 — 1 — 1 2495 | | 


1 1 2822 1 — 1 — 1 2671 | | 
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1 RCTLUHIT 
1 


1 Shared 
1 Sub- 
1 chan- 
1 nel 




RDEVICE 


Type of 
Device 


1 

1 1 

|CUTYPE=| FEATURE= 


DEVT¥PE=| 


Other Operands 


Onit 
Record 
Input 
Devices 


1 2826 1 — 
1 


1 — 


1017 1 




1 2501 1 — 
1 1 


1 — 

1 


2501 1 




Special 
Devices 


1 CTCA 1 — 
1 1 


1 yes 

1 


CTCA 1 
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Appendix C: Representative Directory Entries 



The following sample VM/370 directory entries provide an operating 
system with the entries necessary for operation and updating. The 
indenting shown in the sample directory entries is for clarity only, and 
is not required by the Directory program. Blank cards and cards with an 
asterisk (*) are ignored. LIMK control statements are used whenever 
possible to minimize the number of changes to the Vll/370 directory 
whenever a minidisk extent is moved. A brief explanation of some of the 
virtual machine userids follows. 



I i^ OIIMIOBIS VIBTOAL MACHIHE (OPEHATOg) 

I The userid for this virtual machine must be the same as the userid that 
I you specified on the SYSOPER operand of the SYSOPR macro. The operator 
I is given all command privilege classes except class F. Actually, if 
I other virtual machines are defined with command privilege classes 
j appropriate for updating VM/370, the operator's virtual machine only 
I needs class A command privileges. The 191 minidisk that is defined 
I contains CBS files and EXEC procedures, along with the service programs 
I used to update VM/370. 



I 1 IIRTUAL MACHINE THAT RECEIVES SYSTEM DUMPS (OPERATHS) 

I The userid for this virtual machine is the userid you specified on the 
I SYSDDMP operand of the SYSOPR macro. OPERATHS is the default userid. 
I All abnormal termination dumps are sent to this virtual machine. This 
I user is normally given command privilege classes A, B, C, and E. You 
I also need a virtual machine that contains all of the disks normally 
I attached to the system described as full-volume minidisks if you want to 
I rewrite the VM/370 directory by using the DIRECT command. The operations 
I group can examine any disk while it is attached to the system, if you 
I define these disks as full-volume minidisks. 

I Also, if you plan to use the DDR program to back up the system, you 
I should have all the disks that are normally backed up assigned a fixed 
I virtual address. Then a CMS file containing the DDR control statements 
I can be used to back up the system. Users should not be allowed to write 
I on any disk while that disk is being backed up by the system. You can 
I define additional virtual machines for system backup so that several 
I disks can be backed up at the same time. When you back up several disks 
I at the same time the tape operations can be overlapped. 



I 1 VIRTUAL MACHINE FOR UPDATING AND SUPPORTING VM/370 (MAINT) 

I This virtual machine (MAINT) can support and update the VM/370 system. 

I The 194 minidsk is be used to contain any alterations or fixes to the CP 

I system after they are thoroughly tested and considered stable. The 394 

I minidisk contains the distributed source files. The MAINT virtual 

I machine has class E and class G command privileges, so that it can issue 

I the SAVESYS command to save CMS. The 190 minidisk contains the CMS 

I nucleus and all of the CMS modules and EXEC procedures available to all 
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I CMS users. Any virtual machine that wants to use the CMS system, links 
I to this disk (190) . The 393 minidisk contains the distributed CMS 
I source code in an unaltered form. The 193 minidisk holds CMS PTFs and 
I updates. 



I 1 HARDWARE SERVICE VIRTUAL MACHINE (SRIIINT) 

I This virtual machine (SRMAINT) is normally used by the hardware service 

I representative. Usually, this is the only virtual machine that has 

I command privilege class F. Hhen a virtual machine with class F command 

I privileges logs on, outboard recording is terminated. With class F 

I command privileges, you can set the recording mode for a device, set the 

I mode for recording soft errors, and execute the EREP program. The 

I minidisk is used for diagnostics, CMS EXEC procedures, the CPEREP 

I program, or any other programs used by the hardware support 

I representative. 



I CMS VIRTUAL MACHINES (USERJ, USER 2, AND USER 3) 

I These virtual machines have a typical configuration for CMS users; they 
I each have a minimum CMS configuration. 



I h liTCH VIRTUAL MACHINE (BATCH) 

I The sample batch virtual machine (BATCH) has a timer and the ISAM 
I option. These may or may not be needed depending upon the type of batch 
I system executing: OS, DOS or CMS. This example also shows that two 
I disks are dedicated to this virtual machine. They are BATCHI and 
I BATCH2. They are attached to this virtual machine at logon time if they 
I are mounted and not in use by anyone on the system. 



I h mZlZO IIBTUAL MACHINE (TESTSYS) 

I This virtual machine has the ECMODE option, and could be used to check a 
I new CP nucleus before moving that nucleus to the floor system. TESTSYS 
I contains two minidisks, 330 and 331. These disks are exact copies of 
I the real system residence and scratch volumes. They are formatted and 
I allocated so that the real system can spool and page on these disks. If 
I you need additional disks, link to those disks before you IPL the 
I virtual VM/370 system. 



I THE REMOTE SPOOLING COMMUNICATIONS SUBSYSTEM (RSCS) VIRTUAL MACHINE 

I This virtual machine executes the Remote Spooling Communications 

I Subsystem component of VM/370. Files to be transmitted are addressed to 

I the virtual reader. Virtual punches and printers are dynamically defined 

I and detached by RSCS, as reguired. The 190 virtual disk contains the 

I RSCS nucleus, RSCS modules, and the line driver programs. The binary 

I synchronous lines, dedicated to RSCS, are allocated and deallocated by 

I RSCS as reguired to transmit files to and from remote stations. 
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The following is a sample VM/370 directory file containing entries 
that correspond to the preceding virtual machine descriptions. 



FILE: DSEB DIRECT 

* OSER DIRECTORY DECK 

DIRECTORY 330 3330 SYSRES 

USER OPERATOR PASSWORD 256K 1M ABCDEG 
ACCCUHT NUMBER BIN1 

CONSOLE 009 3215 

SPOOL C 2540 READER A 

SPOOL D 2540 PUNCH A 

SPOOL E 1403 A 

LINK CMSSYS 190 190 RR 

MDISK 191 2314 1 10 UDISK1 WR RPASS WPASS 



USER OPERATNS PASSWORD 256K 1M ABC 








ACCOUNT NUMBER BIN2 








CONSOLE 009 3215 








SPOOL C 2540 READER A 








SPOOL D 2540 PUNCH A 








SPOOL E 1403 A 








LINK CMSSYS 190 190 RR 








MDISK 191 2314 101 10 UDISK1 WR RPASS WPASS 


MDISK 330 3330 404 SYSRES 


WR 


RPASS 


WPASS 


MDISK 331 3330 404 SYSWRK 


RR 


RPASS 


WPASS 


MDISK 230 2314 203 UDISKI 


RR 


RPASS 


WPASS 


MDISK 231 2314 203 UDISK2 


RR 


RPASS 


WPASS 


MDISK 232 2314 203 BATCH1 


RR 


RPASS 


WPASS 


MDISK 233 2314 203 BATCH2 


RR 


RPASS 


WPASS 


MDISK 234 2314 203 APLRES 


RR 


RPASS 


WPASS 


MDISK 235 2314 203 APLWRK 


RR 


RPASS 


WPASS 



USER MAINT CPCMS 512K 16M BCEG 

ACCOUNT installation defined 
OPTION ECMODE REALTIMER 






SPOOL 




OOC 


2540 


READER 


A 




SPOOL 




OOD 


2540 


PUNCH 


A 




SPOOL 




OOE 


1403 


A 






MDISK 


190 


2314 


035 


110 


CPV2L0 


MR 


READ 


MDISK 


191 


2314 


019 


010 


CPV2L0 


MR 


READ 


MDISK 


194 


2314 


145 


058 


CPV2L0 


MR 


READ 


MDISK 


199 


2314 


034 


001 


CPV2L0 


WR 


READ 


MDISK 


193 


2314 


001 


050 


USERD1 


MR 


READ 


MDISK 


294 


2314 


051 


050 


USERD1 


MR 


READ 


MDISK 


393 


2314 


001 


110 


USERD2 


MR 


READ 


MDISK 


394 


2314 


001 


110 


DSERD3 


MR 


READ 


MDISK 


390 


2314 


101 


003 


USERD1 


MW 


READ 


MDISK 


XXX 


2314 


000 


203 


yyyyyy 


MW 





USER SRMAINT PASSWORD 256K 1M FG 
ACCOUNT NUMBER BIN5 

CONSOLE 009 3215 

SPOOL C 2540 READER A 

SPOOL D 2540 PUNCH A 

SPOOL E 1403 A 

LINK CMSSYS 190 190 RR 

MDISK 191 2314 51 10 UDISKI WR RPASS WPASS 
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USER USEB1 FASSNOBD 

ACCOUNT NUMBER BIN7 

CONSOLE 009 3215 

SPOOL C 25U0 READER 

SPOOL D 2540 PUNCH 

SPOOL E mo3 

LINK CMSSYS 190 190 RR 

MDISK 191 231U 71 10 UDISK1 WR RPASS WPASS 

USER USER2 PASSWORD 

ACCOUNT NUMBER BINS 

CONSOLE 009 3215 

SPOOL C 2540 READER 

SPOOL D 2540 PUNCH 

SPOOL E 1403 

LINK CMSSYS 190 190 RR 

MDISK 191 2314 81 10 UDISK1 WR RPASS WPASS 

USER USER3 PASSWORD 

ACCOUNT NUMBER BIN9 

CONSOLE 009 3215 

SPOOL C 2540 READER 

SPOOL D 2540 PUNCH 

SPOOL E 1403 

LINK CMSSYS 190 190 RR 

MDISK 191 2314 91 10 UDISK1 WR RPASS WPASS 

USER BATCH PASSWORD 512K 
ACCOUNT NUMBER BINIO 
OPTION REALTIMER ISAM 

CONSOLE 009 3215 

SPOOL C 2540 READER 

SPOOL D 2540 PUNCH 

SPOOL E 1403 

DEDICATE 230 BATCH1 

DEDICATE 231 BATCH2 

USER TESTSYS PASSWORD 512K 
ACCOUNT NUMBER BIN11 
OPTION ECMODE 

CONSOLE OIF 3215 

SPOOL C 2540 READER 

SPOOL D 2540 PUNCH 

SPOOL E 1403 

LINK CMSSYS 190 190 R 

MDISK 330 3330 1 15 SYSWRK WR RPASS WPASS 

MDISK 331 3330 16 20 SYSWRK WR RPASS WPASS 

USER RSCS PASSWORD 512K 

ACCOUNT NUMBER BIN11A 
CONSOLE OIF 3215 
SPOOL C 2540 READER 
MDISK 190 2314 020 005 CMSVLI R 
DEDICATE OBI 078 
DEDICATE 0B2 079 
DEDICATE 0B3 07A 

USER 2780 PASSWORD 

ACCOUNT NUMBER BIN12 
OPTION REALTIMER 

CONSOLE OIF 3215 

SPOOL C 2540 READER 

SPOOL D 2540 PUNCH 

SPOOL E 1403 

DEDICATE 30 30 
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USER JFK PASSWOBD 512K 

ACCOUNT NUMBER BIN13 
CONSOLE DIP 3215 
SPOOL C 2540 READER 
SPOOL D 2540 PUNCH 
SPOOL E 1403 

MDISK 230 2314 000 050 OSDOSI WR 
MDISK 231 2314 100 020 OSDOSI WR 
BDISK 232 2314 031 030 CPVOLI WR 

USER JCE PASSWORD 

ACCOUNT NUMBER BIN14 
CONSOLE OIF 3215 
SPOOL C 2540 READER 
SPOOL D 2540 PUNCH 
SPOOL E 1403 

MDISK 130 2314 050 050 OSDOSI WR 
MDISK 131 2314 001 020 CPVOLI WR 

USER APLSYS PASSWORD 

ACCOUNT NUMBER BIN15 
CONSOLE OIF 3215 
SPOOL C 2540 READER 
SPOOL D 2540 PUNCH 
SPOOL E 1403 
DEDICATE 191 APLSYS 
DEDICATE 190 APLWRK 
SPECIAL 80 2702 IBM 
SPECIAL 81 2702 lEM 
SPECIAL 82 2702 IBM 
SPECIAL 83 2702 IBM 

USER 0S2 PASSWORD 

ACCOUNT NUMBER BIN16 
CONSOLE OIF 3215 
SPOOL C 2540 READER 
SPOOL D 2540 PUNCH 
SPOOL E 1403 
LINK JFK 230 230 RR 
LINK CMSSYS 190 190 RR 
MDISK 231 2314 120 82 W 
MDISK 191 2314 101 10 UDISK1 WR RPASS WPASS 
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Appendix D: CP/CMS Nucleus/Module Regeneration Requirements 



Whenever a PTF is applied to CMS source code, either the CMS nucleus, or 
some CMS module, or both, must be regenerated. The following table 
shows which must be regenerated in each case, (If a source name does 
not appear in the table, only the CMS nucleus needs to be regenerated.) 



I Change in | 



Requires Regeneration 
of Module/Nucleus 



I EXEC Proce-I 
* dure To Use ' 



1 DMSACC 


ACCESS, Nucleus 


CMSGEND 


1 DMSACF 


ACCESS, Nucleus 


CMSGEND 


1 DMSACM 


ACCESS, Nucleus 


CMSGEND 


1 DMSALU 


ACCESS, FORMAT, RELEASE, Nucleus 


CMSGEND 


1 DMSARE 


RELEASE 




CMSGEND 


1 DMSASD 


ASSEMBLE 




ASMGEND 


1 DMSASM 


ASSEMBLE 




CMSGEND 


1 DMSBSC 


BASIC 




BSCGEND 


1 DMSBTB 


CMSBATCH 




CMSGEND 


1 DMSCMP 


COMPARE 




CMSGEND 


1 DMSCPY 


COPYFILE 




CMSGEND 


1 DMSDSK 


DISK 




CMSGEND 


1 DMSEDC 


EDIT (see 


Note) 


CMSGEND 


1 DMSEDF 


EDIT (see 


Note) 


CMSGEND 


1 DMSEDI 


EDIT (see 


Note) 


CMSGEND 


1 DMSEDX 


EDIT (see 


Note) 


CMSGEND 


1 DMSEXT 


DMSEXT 




CMSGEND 


1 DMSFLD 


FILEDEF 




CMSGEND 


1 DMSFOR 


FORMAT 




CMSGEND 


1 DMSGIO 


EDIT (see 


Note) 


CMSGEND 


1 DMSGLB 


GLOBAL 




CMSGEND 


1 DMSGND 


GENDIRT 




CMSGEND 


1 DMSHDI 


HNDINT 




CMSGEND 


1 DMSHDS 


HNDSVC 




CMSGEND 


1 DMSLBM 


MACLIB 




CMSGEND 


1 DMSIBT 


TXTLIE 




CMSGEND 


1 DMSLDS 


LISTDS 




CMSGEND 


1 DMSLST 


LISTFILE 




CMSGEND 


1 DMSMDP 


MODMAP 




CMSGEND 


1 DMSMVE 


MOVEFILE 




CMSGEND 


1 DMSOVR 


SVCTRACE 




CMSGEND 


1 DMSOVS 


DMSOVS 




CMSGEND 


1 DMSPRT 


PRINT 




CMSGEND 


1 DMSPUN 


PUNCH 




CMSGEND 


1 DMSQRY 


QUERY 




CMSGEND 


1 DMSRDC 


READCARD 




CMSGEND 


1 DMSRNM 


RENAME 




CMSGEND 


1 DMSSCR 


EDIT (see 


Note) 


CMSGEND 


1 DMSSET 


SET 




CMSGEND 


1 DMSSRT 


SORT 




CMSGEND 


1 DMSSVT 


DMSSVT 




CMSGEND 


1 DMSSYN 


SYNONYM 




CMSGEND 


1 DMSTPD 


TAPPDS 




CMSGEND 


1 DMSTPE 


TAPE 




CMSGEND 


1 DMSTYP 


TYPE 




CMSGEND 


1 DMSUPD 


UPDATE 




CMSGEND 


1 DMSZAP 


ZAP 




CMSGEND 
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Hote: When the CMSGEND EXEC procedure is invoked for EDIT, it creates 
the EDIT module, and then automatically reinvokes itself to create the 
EDINIT module. 

If you must regenerate the CMS nucleus, see the "Generating the CMS 
Nucleus" and "Using VMFLCAD to Generate a New Nucleus" sections of "Part 
6: Updating VM/370." 

If a CMS module must be regenerated, see the "Using the CMSGEND EXEC 
Procedure to Generate A CMS Module" and "Creating CMS Disk-Besident 
Modules" sections of "Part 6: Updating VM/370." 

If you apply a PTF to certain CP source programs, the corresponding 

CMS modules must be regenerated also to run properly. The source name, 

module name, and procedures used for regenerating the module are shown 
in the following table. 



Change in 


Regenerate Modul 


e 




Source 




Name Reguired 




EXEC Procedures to Use 


DMKDDR 




DDR 




1 GENERATE, CMSGEND 


DMKDIR 




DIRECT 




GENERATE, CMSGEND 


DMKEDM 




VMPDUMP 




CMSGEND 


DMKFMT 


No 


module name — d 


oes 


GENERATE 




not 


execute under 


CMS 




DHKRND 




NCPDUMP 




CMSGEND 


DMSABN 




ASM3705 




LOADCC 


DMSGRN 




GEN3705 




CMSGEND 


DMSNCP 




SAVENCP 




CMSGEND 



I The LOADCC EXEC procedure is described in "Part 4: Generating the 
I 3704/3705 Control Program;" all the other EXEC procedures are described 
I in "Part 6: Updating VM/370." 
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Appendix E: Notational Conventions 



The notation used to define the command syntax in this publication is: 

• Truncations and Abbreviations of Commands 

Where truncation of a command name is permitted, the shortest 
acceptable version of the command is represented by uppercase 
letters. (Remember, however, that VM/370 commands can be entered 
with any combination of upper and lowercase letters.) The example 
below shows the format specification for the FILEDEF command. 

Flledef 

This representation means that FI , FIL, FILE, FILED, FILEDE, and 
FILEDEF are all valid specifications for this command name. 

Operands and options are specified in the same manner. Where 
truncation is permitted, the shortest acceptable version of the 
operand or option is represented by uppercase letters in the command 
format box. If no minimum truncation is noted, the entire word 
(represented by all capital letters) must be entered. 

Abbreviations are shorter forms of command names, operands, and 
options. Abbreviations for command names are shown below the full 
name in the format box. Abbreviations for operands and options are 
shown in the description of the individual operands and options that 
follows the format box. For example, the operand READER has both a 
minimum truncation and an abbreviation. In the format box it is 
shown as: 

Reader 

indicating that the minimum truncation is R. In the discussion of 
the READER operand that follows, it is shown as: 

READER 
RDR 

indicating that the abbreviation is RDR. Thus, the acceptable 
specifications for the READER operand are: R, RE, REA, READ, READE, 
READER, and RDR. 

In some cases what appears to be a minimum truncation is really the 
only valid abbreviation. For example, the abbreviation for MEMBER is 
MEM. Only these two forms are valid and no truncations are allowed. 
The format box contains 



MEMBER 



I name I 

and the description that follows the format box is 
I name I 



MEMBER 
MEM 
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I • The following symbols are used to define the conmand format and 

I should never be typed when the actual command is entered. 

I underscore _ 

I braces { } 

I brackets [ ] 

I ellipsis ... 

I • Uppercase letters and words, and the following symbols, should be 

I entered as specified in the format box. 

I asterisk * 

I comma , 

I hyphen 

I egual sign = 

I parentheses ( ) 

I period 

I colon : 

I • Lowercase letters, words, and symbols that appear in the command 

i format box represent variables for which specific information should 

I be substituted. For example, "fn ft fm" indicates that file 

I identifiers such as "MYFILE EXEC A1" should be entered. 

I • Choices are represented in the command format boxes by stacking. 

I A 

I B 

I c 

I • An underscore indicates an assumed default option. If an underscored 

I choice is selected, it need not be specified when the command is 

I entered. 



Example 

I A 

I B 

I c 

I indicates that either A, B, or C may be selected. However, if E is 
I selected, it need not be specified. Or, if none is entered, B is 
I assumed. 

I • The use of braces denotes choices, one of which must be selected. 

I Example 

I The representation 

A 
B 
C 

I indicates that you must specify either A, or B, or C. If a list of 
I choices is enclosed by neither brackets or braces, it is to be 
I treated as if enclosed by braces. 
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I • The use of brackets denotes choices, one of which maj be selected. 

I Example 

I The representation 

I r T 

I I A I 

I I E I 

i i C I 

i indicates that you may enter &, B, or C, or you may omit the field. 

I • An ellipsis indicates that the preceding item or group of items may 

i be repeated more than once in succession. 

I Jxam£le 

I The representation 

I (options...) 

I indicates that more than one option may be coded within the 

I parentheses. 
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Appendix F: VM/370 Service Programs Used During System Generation 



The following VM/370 service programs are used when you generate VM/370: 

• The VM/370 Directory program (DMKDIR) 

• The DASD Dump Restore program (DMKDDR) 

• The IBCDASDI Virtual Disk Initialization program (IBCDASDI) 

• The Format/Allocate program (DMKFMT) 

The VM/370 Directory program is described in "Part 2: Defining Your 
VM/370 System"; the others are described in this Appendix, 
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DASD DUMP RESTORE (DDR) SERVICE PROGRAM AND HOW TO USE IT 

Use the DASD Dump Restore (DDR) service program to dump, restore, copy, 
or print VM/370 user minidisks. The DDR program may run as a standalone 
program, or under CMS via the DDR command. 

The DDR program has five functions: 

1. Dumps part or all of the data from a DASD device to tape. 

2. Transfers data from tapes created by the DDR DUMP function to a 
direct access device. The direct access device must be the same as 
that which originally contained the data. 

3. Copies data from one device to another of the same type. Data may 
be reordered, by cylinder, when copied from disk to disk. In order 
to copy one tape to another, the original tape must have been 
created by the DDR DUMP function. 

4. Prints selected parts of DASD and tape records in hexadecimal and 
EBCDIC on the virtual printer. 

5. Displays selected parts of DASD and tape records in hexadecimal and 
EBCDIC on the terminal. 

To generate the VM/370 starter system from the distribution tape, the 
standalone RESTORE function must be used. 



INVOKING DDR UNDER CMS 



The format of the DDR command is: 



II r T 

I DDR I [filename [filetype |filemode| ] ] 

I I 1*1 

i I 



L J 



where : 

filename filetype [filemode] is the identification of the file 

containing the control statements for the 
DDR program. If no file identification is 
provided, the DDR program attempts to 
obtain control statements from the 
console. The filemode defaults to * if a 
value is not provided, 

I Note: If you use the CMS DDR command, CMS ignores the SYSPRINT control 
I statement and directs the output to the CMS printer OOE, 



INVOKING DDR AS A STANDALONE PROGRAM 

To use DDR as a standalone program, the operator should IPL it from a 
real or virtual IPL device as he would any other standalone program. 
Then indicate where the DDR program is to obtain its control statements 
by responding to prompting messages at the console, 

354 VM/370: Planning S System Generation Guide 



DDR CONTROL STATEMENTS 



DDR control statements describe the intended processing and the needed 
I/O devices. I/O definition statements must be specified first. 

All control statements may be entered from either the console or the 
card reader. Only columns 1 to 71 are inspected by the program. All 
data after the last operand in a statement is ignored. An output tape 
must have the DASD cylinder header records in ascending sequences; 
therefore, the extents must be entered in sequence by cylinder. Onlv 
one type of function - dump, restore, or copy - may be performed in one 
execution, but up to 20 statements describing cylinder extents may be 
entered. The function statements are delimited by an input or output 
statement, or by a null line if the console is used for input. If 
additional functions are to be performed, the sequence of certain 
control cards must be repeated. Only those statements needed to 
redefine the I/O devices are necessary for subsequent steps. All other 
I/O definitions remain the same. 

To return to CMS, enter a null line (carriage return) in response to 
the prompting message (ENTER:) . To return directly to CP, key in #CP. 

The PRINT and TYPE statements work differently from other DDR control 
statements in that they operate on only one data extent at a time. If 
the input is from a tape created by the dump function, it must be 
positioned at the header record for each step. The PRINT and TYPE 
statements have an implied output of either the console (TYPE) or system 
printer (PRINT) . Therefore, PRINT and TYPE statements need not be 
delimited by an input or output statement. 



I/O DEFINITION STATEMENTS 



The I/O definition statements describe the tape, DASD, and 
devices used while executing the DASD Dump Restore program. 



printer 



INPUT/OUTPUT Control Statement 



An INPUT or OUTPUT statement describes each tape and DASD unit used, 
The format of the INPUT/OUTPUT statement is: 




r T 

cuu type |volser| [(options...)] 
I altape | 

L J 

0£ ti on s : 

r T r T r i 

ISKip nn| |MOde 6250| |REHind| 

|SKi£ I IMOde 16001 |UNload| 

•- -» IMOde 8001 ILEave | 

L J L J 
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where : 

I INPUT indicates that the device described is an input device. 

I OUTPUT indicates that the device described is an output device. 

cuu is the unit address of the device. 

I type is the device type (2314, 2319, 3330, 3330-11, 3340-35, 

I 3340-70, 2305-1, 2305-2, 2400, 2420, or 3420) (no 7-track 

I support for any tape devices) . Specify a 3410 device as a 

I 3420, a 3340-70F as a 3340-70, and a 3333 as a 3330. 

I ^2i§« The DASD Dump Restore (DDR) program, executing in a 

I virtual machine, uses I/O DIAGNOSE 20 to perform I/O 

I operations on tape and DASD devices. DDR under CMS requires 

I that the device type entered agree with the device type of the 

I real device as recognized by VM/370. If there is a conflict 

I with device types, the following message is issued: 

I DBKDDR701E INVALID OPTION 

I However, if DDR executes standalone in a virtual machine, DDR 

I uses DIAGNOSE 20 to perform the I/O operation if the device 

I types agree and SIO if the device types do not agree. 

volser is the volume serial number of a DASD device. If the keyword 
'SCRATCH' is specified instead of the volume serial number, no 
label verification is performed. 

altape is the address of an alternate tape drive. 

Note: If multiple reels of tape are required and "altape" is 
not specified, DDR types the following at the end of the reel: 

END OF VOLUME CYL XXX HD XXX, MOUNT NEXT TAPE 

After the new tape is mounted, DDR continues automatically. 

Options 

SKIP nn forward spaces nn files on the tape. nn is any number up to 
255. The SKIP option is reset to zero after the tape has been 
positioned . 

MODE 6250 causes all output tapes that are opened for the first time 

I MODE 1600 and at the load point to be written or read in the specified 

MODE 800 density. All subsequent tapes mounted are also set to the 

specified density. If no mode option is specified, then no 

I mode set is performed and the density setting remains as it 

previously was. 

REWIND rewinds the tape at the end of a function. 

UNLOAD rewinds and unloads the tape at the end of a function. 

LEAVE leaves the tape positioned at the end of the file at the end 
of a function. 
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SYSPRIMT Control Statement 

Ose the SYSPRINT control statement (in the standalone application only) 
to describe the printer that is to print data extents specified by the 
PRINT statement. It also can print a map of the cylinder extents from 
the DUMP, RESTORE, or COPY statement. If the SYSPRINT statement is not 
provided, the printer assignment defaults to OOE. CMS ignores the 
SYSPRINT statement when you invoke DDR as a command under CMS, and CMS 
always directs the output to OOE, The format of the SYSPRINT control 
statement is: 

I 1 

I SYsprint | cuu | 

I 1 

where : 

cuu specifies the unit address of the device. 



ZS.Ilction Statements 

The function statements tell the DDR program what action to perform. 
The function commands also describe the extents to be dumped, copied, or 
restored. , The format of the DUMP/COPY/RESTORE control statement is: 



, 




1 r 


- - - - - T 

T 1 




DUmp 


1 icyll [To] 


[cyl2 [Reorder] [To] [cyl3]] | | 




copy 


ICPvol 


1 1 




REstore 


1 lALL 
(Nucleus 


i i 
1 i 


1 




L 


J 1 

., . . ...._,., 1 



where : 

DUMP requests the program to move data from a direct access volume 
onto a magnetic tape or tapes. The data is moved cylinder by 
cylinder. Any number of cylinders may be moved. The format 
of the resulting tape is: 

l^cord J: a volume header record, consisting of data 
describing the volumes. 

5§£2£d 2: a track header record, consisting of a list of count 
fields to restore the track, and the number of data records 
written on tape. After the last count field the record 
contains key and data records to fill the 4K buffer. 

Record 3: track data records, consisting of key and data 
records packed into 4K blocks, with the last record 
truncated. 

Record jl: either the end— of-volume or end-of-job trailer 
label. The end volume label contains the same information as 
the next volume header record except that the ID field 
contains EOV. The end— of-job trailer label contains the same 
information as record 1 except that the cylinder number field 
contains the disk address of the last record on tape and the 
ID field contains EOJ. 
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COPY requests the program to copy data from one device to another 
device of the same or equivalent type. Data may be recorded 
on a cylinder basis from input device to output device. A 
tape-to-tape copy can be accomplished only with data dumped by 
this program. 

RESTORE requests the program to return data that has been dumped by 
this program. Data can be restored only to a DASD volume of 
the same or equivalent device type from which it was dumped. 
It is possible to dump from a real disk and restore to a 
minidisk as long as the device types are the same. 

cyll [TO] [cyl2 [REORDER] [TO] [cyl3]] 

Only those cylinders specified are moved, starting with the 
first track of the first cylinder (cyll), and ending with the 
last track of the second cylinder (cyl2) . The REORDER operand 
causes the output to be reordered, starting at the specified 
cylinder (cyl3) or at the starting cylinder (cyll) if "cyl3" 
is not specified. The REORDER operand must not be specified 
unless specified limits are defined for the operation; the 
starting and, if required, ending cylinders (cyll and cyl2) 
must be specified. 

CPVOL specifies that cylinder and all active directory and 
permanent disk space are to be copied, dumped, or restored. 
This indicates that both source and target disk must be in CP 
format, that is, the CP Format/Allocate service program must 
have formatted them. 

ALL specifies that the operation is to be performed on all 
cylinders. 

NUCLEUS specifies that record 2 on cylinder 0, track and the nucleus 
cylinders will be dumped, copied, or restored. 

E§st r ict ions : 

1. Each track must contain a valid home address, containing the real 
cylinder and track location. 

2. Record zero must not contain more than eight key and/or data 
characters. 

3. Flagged tracks are treated just as any other track for all 2314, 
2319, 33U0, and 2305 devices. That is, no attempt is made to 
substitute the alternate track data when a defective primary track 
is read. In addition, tracks are not inspected to determine 
whether they were previously flagged when written. Therefore, 
volumes containing flagged tracks should be restored to the same 
cylinders of the volume from which they were dumped. The message 
DMKDDR715E occurs each time a defective track is dumped, copied or 
restored, and the operation continues. 

4. Flagged tracks for a 3330 device are handled automatically by the 
control unit and may never be detected by the program. The program 
may detect a flagged track if, for example, no alternate track is 
assigned to the defective primary track. If a flagged track is 
detected by the program, message DMKEER715E occurs and the 
operation terminates. 



358 VM/370: Planning 6 System Generation Guide 



Ex am£l e : 



INPUT 191 3330 SYSRES 

OOTPOT 180 2400 181 (MODE 800 

SYSPRIKT OOF 

DUMP CPVOL 

INPUT 130 3330 MINIOI 

DUMP 1 TO 50 REORDER 51 

60 70 101 



This example sets the density to 800 bpi, then dumps all pertinent 
data from the voliime labeled 'SYSRES' onto the tape that is mounted on 
unit 180. If the program runs out of room on the first tape, it 
continues dumping onto the alternate device (181) . A map of the dumped 
cylinders is printed on unit OOF while the program is dumping. When the 
first function is complete, the volume labeled 'MINIOI' is dumped onto a 
new tape. Its cylinder header records are labeled 51 to 100. A map of 
the dumped cylinders is printed on unit OOF. Next, cylinders 60 to 70 
are dumped and labeled 101 to 111. This extent is added to the cylinder 
map on unit OOF. When the DDR processing is complete, the tapes are 
unloaded and the program stops. 

If cylinder extents are being defined from the console, the following 
is displayed : 

ENTER CYLINDER EXTENTS 
ENTER: 

For any extent after the first extent, the message 

ENTER NEXT EXTENT OR NULL LINE 
ENTER: 

is displayed. 

The user may then enter additional extents to be dumped, restored, or 
copied. A null line causes the job step to start. 



OINIZTYPE Function Statement 

Use the PRINT and TYPE function statement to print or type (display) a 
hexadecimal and EBCDIC translation of each record specified. The input 
device must be defined as direct access or tape. The output is directed 
to the system console for the TYPE function, or to the SYSPRINT device 
for the PRINT function. (This does not cause redefinition of the output 
unit definition.) The format of the PRINT/TYPE control statement is: 



I 1 

I PRint I cyll [hhl [rrl]] [To cyl2 [ hh2 [rr2 ]]] [(options)] | 
I TYpe I I 

I I 2£^ions: \ 

I I [Hex] [Graphic] [Count] I 

I 1 

w her e : 

cyll is the starting cylinder. 

hhl is the starting track. If present, it must follow the cyll 
operand. The default is track zero. 
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rrl is the starting record. If present, it must follow the hhl 
operand. The default is home address and record zero. 

[TO] cyl2 is the ending cylinder. If more than one cylinder is to be 
printed or typed "TO cyl2" must be specified. 

hh2 is the ending track. If present, it must follow the cyl2 
operand. The default is the last track on the ending 
cylinder. 

rr2 is the record ID of the last record to print. The default is 
the last record on the ending track. 

0£t ions : 

HEX prints or displays a hexadecimal representation of each 
record specified. 

GRAPHIC prints or displays an EBCDIC translation of each record 
specified. 

COUNT prints or displays only the count field for each record 
specified. 



Examples : 
PRINT TO 3 

Prints all of the records from cylinders 0, 1, 2, and 3. 
PRINT 1 3 

Prints only one record, from cylinder 0, track 1, record 3. 

PRINT 1 10 3 TO 1 15 a 

Prints all records starting with cylinder 1, track 10, record 3, 
and ending with cylinder 1, track 15, record 4. 

The example in Figure 31 shows the information displayed at the 
console (TYPE function) or system printer (PRINT function) by the DDR 
program. The listing is annotated to describe some of the data fields. 

I Resfionses 

DMKDDR725R ORIGINAL INPUT DEVICE WAS (IS) LARGER THAN OUTPUT DEVICE. 
DO YOU WISH TO CONTINUE? RESPONSE YES OR NO: 

Ixplanation: 

RESTORE function - The number of cylinders on the original DASD 

input unit is compared with the number of cylinders on the output 

device. 

COPY function - The input device contains more cylinders than the 
output device. 

0£®iator Act io n: The operator must determine if the COPY or RESTORE 
function is to continue. The response is either yes or no. 
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DMKDDR711R VOLID READ IS volid2 [NOT volidi] 

DO YOU WISH TO CONTINUE? RESPOND YES NO OR REREAD: 

where: 



vuxxu.^ J.O cue: 

DASD unit. 



.,.4 ^T n .,».K. 



volidi is the volume serial number from the INPUT or OUTPUT 
control card. 

The volume serial number read from the device at cuu is not the 
same as that specified on the INPUT or OUTPUT control card. 

DMKDDR716R NO VOL 1 LABEL FOUND FOR volser 

DO YOU WISH TO CONTINUE? RESPOND YES NO OR REREAD: 

w her e : 

volser is the volume serial number of the DASD device from the 
INPUT or the OUTPUT control card. 

The DASD device at cuu contains no volume serial number, 

DMKDDR717R DATA DUMPED FROM volidi TO BE RESTORED to volid2 

DO YOU WISH TO CONTINUE? RESPOND YES NO OR REREAD: 

where : 

volidi is the volume serial number from the input tape header 
record (volume dumped) . 

volid2 is the volume serial number from the output DASD device. 

The above message is printed to verify the input parameters. 
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Home Address- 
Record 



Record 1 



1st Half of - 
Record 2 



Home Address 
Record 

2nd Half of 
Record 2 



Record 3 



Record 4 



*^ JCYL 019 HP OOJ 



HOME ADDRESS 0000130000 IRECORD ZERO 0013000000 



Cylinder and head 
identification for 
Record 



WOO I 



Home Address of track 
in hexadecimal format 



Record ID from the 
count field 



Key I Data 
Len I Length 
(hexadecimal) 



Data 
(hexadecimal) 



019 HD 00 REC 001 1 COUNT 0013000001 



•- |CYL019HDOOREC001| 



Cylinder, head, and 
record numbers in 
decimal 



Record ID 
(hexadecimal) 



04096 1000 DATA LENGTH 




n 



If the data length field is not zero 

A heading is printed containing the I 

data length from the count field first in | 

decimal, then in hexadecimal . 

The data is then printed in hexadecimal I 
with graphic interpretation to the right 

(not shown here). I 



00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
SUPPRESSED CHARACTERS SAME AS ABOVE . . . 



CYL 019.HD 00 REC 002 COUNT 0013000002 00I09A8 



02472 |09A8| DATA LENGTH 



Note: Data Length field repeated 
in heading. 



00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
SUPPRESSED CHARACTERS SAME AS ABOVE . . . 



ABOVE RECORD WRITTEN USING RECORD OVERFLOW 



r©" 



This statement indicates that this portion ■ 
of Record 2 was written using the Write I 

Special Count, Key, and Data command. The 
remainder of Record 2 is found on the next I 
track as the first record after Record 0. 



CYL 019 HD 01 HOME ADDRESS 0000130001 RECORD ZERO 0013000100 00 0008 00000000 00000000 

■CYL 019 HD 01 REC 002 COUNT 0013000102 00 0658-* 

01624 0658 DATA LENGTH 

00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
SUPPRESSED CHARACTERS SAME AS ABOVE . . . 



e 



CYL 019 HD 01 REC 003 COUNT 0013000103 80 0F80 
00128 0080 KEY LENGTH -« 




^^ If the key length field is not zero 

A heading is printed containing the key length 
first in decimal, then in hexadecimal. 
, - The key is then printed in hexadecimal with 
/ / graphic interpretation to the right (not shown he 

^''^-/- ■ 
/ 



re). 



00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
SUPPRESSED CHARACTERS SAME AS ABOVE . . . 

03968 0F80 DATA LENGTH 

00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
SUPPRESSED CHARACTERS SAME AS ABOVE . . . 



CYL 019 HD 01 REC 004 COUNT 0013000104 00 0000 
END OF FILE RECORD' 



o 



Whenever the data length field is zero 
an end-of-file prints next. 



n 



Figure 31. Annotated Sample of Output from the TYPE and PRINT Functions of the DDR 
Program 
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I DISK BACKUP VIA DASD DUMP RESTORE SERVICE PROGRAM (DMKDDR) 



EXAMPLES 



I li^am£le 2* 



I You can back up a system volume (MINI01) containing many minidisks and 
I then restore the minidisk named MINIB to a different area on a different 



Real 
Cylinder 



To dump the minidisks 
to tape: 

INPUT 230 2314 MiNiOl 
OUTPUT 180 3420 
DUMP ALL 




To restore iVIINIB to the user's MINID minidisk 
using the tape created above, log on with the 
userid that owns MINID. 

INPUT 180 3420 

OUTPUT 191 2314 MINID 

RESTORE 100 TO 150 REORDER TO 

{Note: The area allocated to MINID on DASD 
volume MINI05 would have been defined in the 
directory. REORDER TO specif ies that 
MINID's virtual cylinders will be to 50.) 




MINI05 
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I llMfile 2: 



I You can dump the VM/370 system residence volunie: 



Real 
Cylinder 

000 

004 
005 




INPUT 330 2314VMDSK1 
OUTPUT 180 3420 
DUMP CPVOL 



197 
198 

200 
201 

202 



SPOOLING 



CP NUCLEUS 




VMDSK1 



When CPVOL is specified with the DUMP or COPY command, cylinder and 
all space allocated for directory and permanent space are dumped or 
copied (DRCT and PERM cylinders are indicated in the byte allocation 
record on cylinder 0) . In this example, the spooling space and all 
nonallocated directory space are not dumped or copied. 

When restoring or copying to a VM/370 disk, it is your responsibility to 
ensure that all data not restored or copied is in the proper format as 
I described in the byte allocation map of the receiving volume. 
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I lxa_m£le 3 : 

I You can copy real volume VMDSKl cylinders 100 to 150 to real volume 
! VMDSK2 cylinders 50 to 100: 

I INPUT 130 2314 VMDSKl 
I OUTPUT 131 2314 VMDSK2 
I COPY 100 TO 150 REORDER TO 50 



I You can copy minidisk 190 containing the CMS system to minidisk 199: 

I INPUT 190 2314 CMSSYS 
I OUTPUT 199 2314 CMSSYS 
I COPY TO 55 

I (The copied CMS system does not require any modifications to be used as 
I a system disk.) 
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I IBCDASpi -- GENERAL Ml^^MllQ.^ 

VM/370 does virtual disk initialization with the OS utility program 
IBCDASDI. IBCDASDI foriats real or virtual VM/370 disk volumes for OS 
and DOS use. Do not use it to format CP disk areas (for paging, 
spooling, and so forth) , or CMS disk areas. The execution of IBCDASDI 
is performed from the virtual card reader and the technigue is described 
in "Invoking IBCDASDI" later in this section. 

INITIALIZIMG A MINIDISK 

IBCDASDI can, in addition to initializing real disks, initialize a 

minidisk. A minidisk can be initialized with or without a surface 

analysis (a test for defective tracks) ; a surface analysis should be 

included when a minidisk is initialized for the first time. Tracks in 
the last cylinders of a 2314 minidisk are left open for assignment as 

alternate tracks. No tracks are saved for alternates on 3330 or 3340 
minidisks. 



IBCDASDI Restrictions: 

The IBCDASDI program cannot check to see if the 3330 or 3340 space to be 
initialized was previously formatted. 

If you format only 5 cylinders of a 5 cylinder virtual disk of a 3330 
or 3340 but specify 20 cylinders to be initialized (CYLNO=20) , the 
IBCDASDI program does not initialize all 20 cylinders but merely updates 
the format 5 label in the VTOC to indicate 20 cylinders without checking 
for the existence of 20 cylinders and without issuing an error message. 
Later, any attempt to use the sixth through the twentieth cylinder 
causes a Seek Check and the channel program abnormally terminates. 

lUiH^lization with Surface Analjsis: 
The IBCDASDI program: 

• Checks for tracks that were previously designated as defective 
(flagged) and have had alternates assigned. The program automatically 

assigns alternate tracks for 2314/2319 disk devices but not 3330s. 

This test must be suppressed when a disk is being initialized with 
I surface analysis for the first time. This test must not be 
I suppressed when a disk is initialized without surface analysis. 

• Performs a surface analysis of each track of a 2314 or 2319 and 
automatically assigns alternates (for 2314/2319s), if necessary. 
Tracks that are available for use as alternates are checked first. 

• Writes a track descriptor record (record 0) , and erases the remainder 
I of each track. When initializing a disk with surface analysis, 
I IBCDASDI also writes a standard home address. 

• Writes IPL records on track (records 1 and 2) . 

• Writes volume label on track (record 3) and provides space for 
additional records, if reguested. 

• Constructs and writes a volume table of contents (VTOC) . 

I • Writes IPL program, if reguested, on track (2314, 2305, 2319, 3330 
I or 3340), or track 1 (2311). 
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Initialization without Surface Analjfsis: 

I The IBCDASDI program: 

I « Checks for tracks that were previously desiguated as defective 

I (flagged) and have had alternates assigned. The program 

I automatically assigns alternates (2314/2319 disk devices only) . This 

I test must not be suppressed. 

Writes a standard home address, a track descriptor record (record 0) , 
and erases the remainder of each tracks 

Writes IPL records on track (records 1 and 2) . 

Writes volume label on track (record 3) and provides space for 
additional records, if requested. 

Constructs and writes a volume table of contents (VTOC) . 

Writes IPL program, if requested, on track (2314, 2305, 3330 or 
3340 devices) or track 1 (2311 disks). 

Note: The IBCDASDI program cannot assign alternate tracks for 3330/3340 
volumes, except when specified by the GETALT statement. Even with the 
GETALT statement, the IBCDASDI program cannot assign alternate tracks 
for a 3330/3340 minidisk because no cylinder has been allocated on which 
to assign alternate tracks. Defective tracks are flagged and alternate 
tracks are assigned when the 3330/3340 storage volumes are initialized 
at the factory. An IBCDASDI job that initializes a 3330/3340 performs 
the "Quick DASDI" function, which reads alternate tracks, decrementing 
the total unit of alternates by one whenever an alternate is found 
defective or assigned, writes a volume label and VTOC, and writes an 
IPLTEXT if requested. Ho surface analysis is performed and no home 
address or record is written on the primary tracks. The BYPASS and 
FLAGTEST options of the DADEF statement are ignored. 

DASD 3340 disk packs are factory-shipped without flagged tracks and 
alternate track assignments. IBCDASDI* s "Quick DASDI" detects 3340 
customer-generated alternate track assignments. 

The IBCDASDI program requires the following function-defining 
statements to initialize direct access volumes; they must appear in the 
following sequence: 

1. JOB Statement; indicates the beginning of the IBCDASDI job. 

2. MSG Statement; defines the output device for operator messages. 

3. DADEF Statement; defines the DASD device to be initialized. 

4. VLD Statement; labels the volume and allocates space for additional 
labels. 

5. VTOCD Statement; controls the location of the 
volume-table-of-contents (VTOC) . 

6. IPLTXT Statement (optional) ; separates service program control 
statements from IPL text statements. 

7. END Statement; indicates the end of an IBCDASDI job or IPL text. 

8. LASTCARD Statement (optional); end of a series of stacked IBCDASDI 
jobs. 
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JOB Statement 



The JOB statement indicates the beginning of a job. The format of the 
JOB statement is: 



|[ name] 



JOB 



|[user information] 



MSG Statement 



The MSG statement defines an output device for operator messages, it 
follows the JCB statement and precedes any function-defining statements 
that are associated with the IBCDASDI program. The format of the MSG 
statement is: 



I [ name ] 



MSG 



|TODEV=XXXX,TOADDR=CUU 



w h er e : 
TODEV=xxxx 

TOADDB=cuu 



is the device type of the message output device (1U03, 

1052, 2400, 3400, 3210, or 3211). 

is the channel number (c) and unit number (uu) of the 
message output device. 



DADEF Statement 



The EADEF statement defines the direct access volume to be initialized. 
The format of the DADEF statement is: 



[ name] 



DADEF 



|TODEV=xxxxxx 

I ,TOADDR=cuu 

|[ ,IPL=YES] 

I? ,VOLID=serial ) 

It ,volid=scratch/ 

|[ ,MODEL=n] 
|[ ,CYLNO=nnn] 



|[ ,FLAGTEST=NO] 
|[ ,PASSES=n] 



|[ ,BYPASS = YES] 
I 



^Applies to initialization with or without surface analysis, 
^Applies to initialization with surface analysis. 
'Applies to initialization without surface analysis. 



368 VM/370: Planning & System Generation Guide 



w h er e : 
TODEV=xxxxxx 



TOADDR=cuu 



IPL=YES 



VOLID=serial 



VOLID=SCRATCH 



MODEL=n 



CYLNO=nnn 



FLAGTEST=NO 



PASSES=n 



is a four- to six-character device type of the direct 
access device. Specify either: 

2305 

2314 

3340 

3330 for 3330 Models 1 or 2 

3330-1 for 3330 Model 11 

is the channel (c) and unit address (uu) of the device. 
Specify the real address of the device if you are 
executing on the real machine; specify the virtual 
address of the device if you are executing on the virtual 
machine. 

writes an IPL program on the minidisk. An IPL 
initialization program must be written on a device to be 
used for system residence. 

If IPL is omitted, no IPL program is written. 

is the volume serial number of the minidisk to be 
initialized. 

If "serial" matches the volume serial number found on the 
minidisk to be initialized, the operation proceeds. If 
it does not match, the operator is notified. 

specifies that no volume serial number check is to be 
made. 

is a decimal model number (1 or 2) . This operand is only 
for the 2305 and corresponds to the 2305-1 and 2305-2, 
respectively. 

is a decimal number which specifies the number of 
cylinders to be formatted. If the CYLNO parameter is 
omitted, IBCDASDI intializes the entire real volume 
specified. 

(applies to surface analysis) specifies that the program 
is not to check for previously flagged tracks before 
surface analysis is attempted on this device. 

(PLAGTBST=HO applies only to 2314 and 2319 devices, and 
should be specified when the disk recording surface is 
initialized for the first time.) 

Note: Because no check is ever made for previously 
flagged tracks on drum volumes, FLAGTEST=NO is not coded 
when these devices are initialized. 

specifies the number of passes per track to be made in 
checking for defective tracks. PASSES is valid when 
surface analysis is to be performed or when a "Quick 
DASDI" is to be performed on a 3330, 3330-1, or 3340 
volume. The value n can be through 255. The 
specification indicates that a "Quick DASDI" is to be 
performed on a 3330, 3330-1, or 3340 volume. For a 3330, 
3330-1, or 3340 volume, a value other than zero causes 
record to be written on each track. Mo check is made 
for defective tracks on a 3330, 3330-1, or 3340. A 
specification of 1 through 255 indicates the number of 
passes to be made per track for volumes other than a 
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I BYPASS=YES 



3330, 3330-1, or 3340 volume, 
pass is made per track. 



If PASSES is omitted, one 



bypasses the program's defective-track checking feature. 

If BYPASS is omitted, tracks are checked and those found 
defective are automatically assigned alternates. This 
operand is ignored if specified for 3330 devices. 



VLD Statement 



The VLD statement labels the volume. 
is: 



The format of the VLD statement 




HEWVOLID=serial 
/ ,V0LPASS=1\ 
I rIOIiPiSSf j 
[ ,OWNERID=xxxxxxxxxx ] 
[,ADDLABEL=n] 



whe re : 

NEWVOLID=serial is a one- to six-character volume serial number. 

V0LPASS=1 sets the volume security bit to 1. 

VOLPASS=0 sets the volume security bit to 0. 

If VOLPASS is omitted, the volume security bit is 
set to 0. 

OWNERID=xxxxxxxxxx is a one- to ten-character field that identifies the 

owner of the volume. 

If OHNERID is omitted, no identification is given. 

Note: The ownerid CP370 is reserved for use by 
DMKFMT and cannot be specified. 

ADDLABEL=n is a number between one and seven that indicates the 

total number of additional labels for which space is 
to be allocated. 

If ADDLABEL is omitted, is assumed. 



VTOCD Statement 



The VTOCD statement contains information for controlling the location of 
the volume table of contents. The format of the VTOCD statement is: 



|[name] | VTOCD | STBTADE=nnnnn 
I I I ,EXTENT=nnnn 
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whe re : 

STRTADR=nnnnn is the one- to five-byte track address, relative to the 
beginning of the minidisk, at which the volume table of 
contents is to begin. The VTOC cannot occupy cylinder 0, 
track 00, or any alternate track. 

EXTENT=nnnnn is the length of the volume table of contents in tracks. 
The number (decimal) of entries per track for each type 



of device is gi 


ven bslow. 


Device 
2301 


VTOC 


Entries/Track 
63 


2314/2319 




25 


2311 




16 


2305-1 




18 


2305-2 




34 


3330-1,2 




39 


3330-11 




39 


3340 




22 



IPLTXT Statement 

The IPLTXT statement separates service program control statements from 
IPL program text statements. It is reguired only when IPL text is 
included. The statement consists of the word IPLTXT, followed by 
blanks. 

When IPL text is included, the END statement must follow it and END 
must start in column 2. 



MP Statement 

The END statement denotes the end of the job. It appears after the last 
function-defining statement. The format of the END statement is: 



I 1 

I [name] |END |[user information] I 

I I 



MJTCARp Statement 

The LASTCARD statement is reguired only when a IBCDASDI job or a series 
of stacked IBCDASDI jobs is followed by other statements on the control 
statement input device. The LASTCARD statement must follow the last END 
statement applying to an IBCDASDI job. It consists of the operand 
LASTCARD, followed by blanks. 
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Example 

The example below shows the control statements that might be prepared to 
initialize minidisk LIBBES for OS data set residence. Note that the 
label of the real volume, CPV0L1, cannot be used as the VOLID operand. 

JOB 

MSG TODEV=1403,TOADDR=00E 

DADEF TCDEV=2314,T0ADDR=231,VOLID=SCRATCH,CYLNO=50 

VLD NEWVOLID=LIBRES,OHNERID=OPERATIONS 

VTOCD STRTADR=10,EXTENT=5 

END 

The desired size of the minidisk is specified through the CYLNO 
operand. The value specified includes one cylinder reserved for 
alternate track assignment; a user assigned n cylinders has n- 1 of these 
initialized for his use, and the nth cylinder used for any alternate 
track assignment. The minimum size of a minidisk can be computed from 
the formula below. In it, N represents the minimum number of cylinders, 
and K represents the number of recording heads of the device. The 
SIZE-OF-VTOC value should be in tracks, and the result of the division 
should be rounded to the next highest integer. 

N = 2 + (SIZE-OF-VTOC / K) 

I Note: For 2305 Models 1 and 2, 3330, and 3340 devices, all n cylinders 
I are assigned for your use. No allowance is made for alternate track 
I assignment. 



ASSIGNING AN ALTERNATE TRACK 

IBCDASDI: (1) analyzes a track and, if necessary, assigns an alternate 
or (2) bypasses testing, and assigns an alternate. You must specify the 
tracks for which you wish alternates with a GETALT statement. 

^Lssigning an Alternate (with Testing) : An alternate track (if available) 
is assigned for a track specified for testing and found defective. If 
the defective track has had an alternate previously assigned, a new 
alternate track is assigned. If the defective track is an unassigned 
alternate track, it is flagged to prevent its future use and another 
alternate track is selected. The alternate track address is made known 
to the operator. 

If a track is tested and found to be "not defective," no alternate is 
assigned. The operator is notified by a message. 

Assi^nina an Alternate (without Testing): The program's defective track 
checking feature can be bypassed, and an alternate track can be assigned 
for any track, whether it is permanently defective or not. If the 
specified track is an alternate, a new alternate track is assigned. If 
the specified track is an unassigned alternate, it is flagged to prevent 
its future use. 

Note: For 3330 and 3340 minidisks you must assign the alternate on the 
real disk. Any references thereafter to that track on the minidisk are 
referred to the alternate track. 
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GET ALT Statement 

Any number of alternate tracks can be assigned in a single job by 

I including one GETALT statement for each tracks The GETALT statement can 

I follow the MSG statement. The format of the GETALT statement is: 



GETALT |TODEV=XXXX 

I ,TOADDR=cuu 

I ,TBACK=cccchhhh 

I rVOLID=serial 

|[,FLAGTEST=NO] 

|[ ,PASSES=n] 

|[,BYPASS=YES] 

I I |[,MODEL=n] ! 

I , , -., I 

w her e : 

TODEV=xxxx is the device type of the direct access device. 

TOADDR=cuu is the channel number (c) and unit number (uu) of the 
direct access device. 

TRACK=cccchhhh is the address of the track for which an alternate is 
requested; where cccc is the cylinder number and hhhh is 
the head number. These are hexadecimal numbers. 

VOLID=serial is the volume serial number of the minidisk to which an 
alternate track is to be assigned. If "serial" matches 
the volume serial number found on this minidisk, the 
alternate track assignment proceeds. If it does not 
match, the operator is notified. 

FLAGTEST=HO (used when testing before assigning an alternate) 
specifies that the program not check for a previously 
flagged track before a surface analysis is attempted on 
this track (disk storage devices only) . 

PASSES=n (used when testing before assigning an alternate) 
specifies that the program's defective track checking 
feature is to make n number of passes (from 1 to 225) 
when performing a surfaqe analysis. If PASSES is 
omitted, one pass is made on this track. 

BYPASS=YES is that the program's defective track checking feature is 
to be bypassed. 

If BYPASS is omitted, the program assigns an alternate 
only if it finds that the specified track is defective. 

HODEL=n is a decimal model number (1 or 2) . This operand is only 
for the 2305 and corresponds to the 2305-1 and 2305-2, 
respectively. 

Note: A list of defective tracks (if any) is provided with new IBM disk 
storage volumes. Refer to this list when using the IBCDASDI program for 
the first time. After initialization, include the GETALT statement in an 
IBCDASDI job to assign an alternate track for each track on the list. 
Subsequent IBCDASDI jobs "remember" those defective tracks, unless the 
FLAGTEST=NO option is specified for those jobs. 
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I INVOKING THE IBCDASDI PROGRAM 

I The IBCDASDI program is invoked for minidisks by specifying the operand 

. . . ,CYLNO=nnn 

on the DADEF control statement (discussed previously) . This control 
statement is passed to the IBCDASDI utility for processing. This 
operand specifies the size, in cylinders, of the minidisk to be 
I initiated. 

The IBCDASDI program, which is distributed as a CMS file with a 
filename of IPL and a filetype of IBCDASDI, should be spooled to your 
own virtual card reader. Control statements for the program can follow 
the last card or card image for the program, or can be entered via a 
separate input device. 

To execute the IBCDASDI program: 

1. Spool a copy of the IBCDASDI object module to your virtual card 
reader, or mount and attach the tape containing the object 
program. 

2. Load the object program from the virtual reader or tape by issuing 
the CP IPL command for the appropriate virtual device address. 
When the program is loaded, an enabled wait state is entered with 
the address field of the PSW containing the hexadecimal value 
FFFF. 

3. When the program is loaded and waiting for input, signal attention 
from the virtual console device. The message 

DEFINE INPUT DEVICE 

is sent to your virtual console. Enter the following response from 
the virtual console: 

INPUT=type,cuu 

whe re : 

type is the device type of the device containing the control 
statements. Valid device types are 2U00, 2540, 3410, 
3420, and 3505. 

cuu is the device address of the device containing the 
control statements. 

Control statements are printed on the message output device. At the 
end of job, the END OF JOB message is printed on the message output 
device and the program enters the wait state. 
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I FORMATTING V0LU1!ES--GENEEAL INFOBMATION 

All direct access volumes used by the VM/370 system (for paging, 
spooling, system residence, directory, or temporary disk allocation) 
must be properly labeled, formatted, and allocated. The CP 
Format/Allocate service program (DMKFMT module) prepares disks for use 
by CP, A CMS FORMAT program is also available and must be used to 
format CMS and RSCS disks. 

Volumes used only by virtual machines other than CMS or RSCS 
(minidisks or dedicated volumes) do not need to be formatted. 

An object deck version of the CP Format/Allocate service program is a 
standalone program and can be loaded from a virtual or real card reader 
in, respectively, a virtual or a real machine. (If run in a virtual 
machine, the virtual machine must have write access to the volume being 
formatted.) The program accepts control statements from the operator's 
system console (commands) or from the IPL device (card reader) . 

Cylinders used by CP for paging, spooling, and so on, must be 
Preformatted with fixed length unblocked records of 4096 bytes. 

Device capacity when formatted for CP use is: 

2314/2319 32 records/cylinder (8 records/5 tracks) 

3330 57 records/cylinder (3 records/track) 

2305 24 records/cylinder (3 records/track) 

3340 24 records/cylinder (2 records/track) 

The format operation writes 4096-byte blocks on all cylinders being 
formatted. The service program does write-checking to verify that parts 
of the track are not defective. Bad surfaces are flagged as allocated 
(in use) in the page bit map and are not used. Alternate tracks are not 
assigned for CP-owned DASD devices. 

For example, the 3330 track format for all formatted cylinders except 
cylinder is shown in Figure 32. 



Track 0: 

RO R1 R2 R3 



11 II II 

II It II 






8 bytes 4096 bytes 4096 bytes 4096 bytes 




R1 R2 R3 



— I 1 1 

II II I 

II II I 



8 bytes 4096 bytes 4096 bytes 4096 bytes 
I 

Figure 32. Format of 3330 Cylinders for Use by CP 
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I Cylinder Format 

All volumes containing space for CP use (paging, spooling, and so on) 
must have a properly formatted cylinder 0. The only service program 
that can do this is the Format/Allocate program (DMKFMT) . 

Cylinder is formatted like other cylinders except that the space 
associated with the first three U096-byte blocks is reserved for system 
use. This area is then formatted as illustrated in Figure 33. 



rack 


BO 




B1 

IPL 1 

rec 1 
1 


B2 




KEY B3 




1 
1 




■■ 1 r- 

1 1 

1 1 
1 1 


1 DMKCKP 
1 Nodule 

• 

4096 


1 
1 


|V| 

10 1 VOLID 

Hi 

HI 
I. 






8 




2U 





80 



84 KEY B5 KEY B6 FB 

//- 



I 1 r 

I Allocation | | | Format | | | Format | | 
I Byte map | I | 4 DSCB | I j 5 DSCB | | 

1024 44 96 44 96 

Track 1 to Track 18 are the same as the nonzero cylinders. 

Figure 33. 3330 Cylinder Format 

The contents of each record in cylinder zero are as follows: 

BO Nothing. 

B1 IPL record — Puts the system into wait state if storage volume is 
loaded before CP nucleus is built. 

B2 Checkpoint record — Used by CP to save and retrieve information 
for a warm start. 

B3 Volume label — Same as OS V0L1 label. On CP system residence 
volume, area in data record marks the beginning of the system 
directory. A label is automatically written when cylinder is 
formatted. The owner field of the label record contains "VM/370" 
if there is allocation data present in B4. 

B4 Allocation Byte Map — Each byte identifies a cylinder and 
specifies its usage (paging, spooling, directory, and so on) . This 
map is filled in by the ALLOCATE function of the DMKFMT service 
program. 

B5 Format 4 OS DSCB type label — For compatibility with OS. 

B6 Format 5 OS DSCB type label — For compatibility with OS. Label 
indicates to OS that no space is available on this volume. 

FB Is one or more filler records. 
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I FORMAT/ALLOCATE SERVICE PROGRAM (DMKFMT) 

I The Format/Allocate service program formats, allocates, and labels 

i dir sct"*access Yolumes for ■•^a-'^in'^ s'^ooli.n'^ and CP file residence* This 

I service program is executed as part of CP system generation procedures 

I and may also te executed as a standalone program to: 

I 1. Format direct-access volumes for CP use. 

I 2. Allocate specific disk areas to particular functions or to CP use. 

I 3. Write six-character volume serial number labels. 

I Note: The Format/Allocate program should be used with care, since it 

I destroys existing data (if any) . Also, user minidisks must not begin on 

I real cylinder zero of CP-owned volumes, because information critical to 

I CP is stored in that cylinder. 

I Format/Allocate program control statements may be supplied in card 

I form via a card reader, or may be entered at the system console. All 

I error messages regarding improper specification of control statements 

I are displayed at the console. If the Format/Allocate service program 

I encounters any unusable disk surfaces, it flags the associated record, 

I but it does not select any alternate tracks. 



I FORMAT/ALLOCATE PROGRAM CARD ISPUT 

I Punch control statements for card input start in column 1, and each 

I field is separated from the adjacent field by a comma. Two commas in a 

I row cause the insertion of a default value. Three commas in a row cause 

I the insertion of two default values. 

I 121® • The only default values permitted are those that define the 

I starting and ending cylinders. The defaults are the first and last 

I cylinders of the volume, respectively. 

I Comments must be preceded by at least three blanks. 

I The control card entries for the Format/Allocate program must be in 

I the following order: 

I • Format function: 

I FORMAT, devadr,devtype,volser,startcyladr, endcyladr 

I • Allocate function: 

I ALLOCATE, devadr,devtype,volser 

I TEMP, startcyladr, endcyladr 

I PERM, startcyladr, endcyladr 

I TDSK, startcyladr, endcyladr 

I DRCT, startcyladr , endcyladr 

I END 

I • Label functions: 

I FORMAT, devadr,devtype,volser, LABEL 

I FORMAT, ALLOCATE, and LABEL are Format/Allocate program control words 

I and may be abbreviated to one letter. 
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I FOMII Control Statement 

I The format of the FORMAT control statement is; 



I I 1 

I I PORMAT,devadr ,devtype,volser ,startcyladr ,endcyladr I 

I I 1 



I w her e : 

I devadr is a three— digit hexadecimal number that identifies the 

I address of the device that the Format/Allocate program is 

I to act upon, 

I devtype is a four- to seven-character field that defines an 

I approved device for the Format/Allocate program. Approved 

I device types are 2314, 2319, 3330, 3330-11, 3340-35, 

I 3340-70, 2305-1, and 2305-2. Specify 3333 as 3330, and 

I 3340-70F as 3340-70. 

I volser is a one- to six-character field that represents the volume 

I serial number of the volume you are formatting. 

I startcyladr is the starting cylinder address on the DASD on which the 

I format function is to be performed. The start cylinder 

I address is entered as decimal digits. 

I endcyladr is the last cylinder address on the DASD en which the 

I format function is to be performed. The end cylinder 

I address is entered as decimal digits. 

I Note: FORMAT is a control word and maybe abbreviated to F. 



I ALLOCATE Control Statements 

I The formats of the ALLOCATE control statements are 



ALLOCATE, devadr, devtype, volser 
TEMP, startcyladr, endcyladr 
PERM, startcyladr, endcyladr 
TDSK, startcyladr, endcyladr 
DRCT, startcyladr, endcyladr 
END 



I w]i§£f: 

I devadr is a three— digit hexadecimal number that identifies the 

I address of the device that the program Format/Allocate is 

I to act upon. 

I devtype is a four- or seven-character field that defines an 

I approved device for the Format/Allocate program. Approved 

I device types are 2314, 2319, 3330, 3330-11, 3340, 2305-1, 

I and 2305-2. 
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volser is a one— to six-character field that represents the volume 
serial number of the volume you are formatting. 

startcyladr is the starting cylinder address on the DASD on which the 
format function is to be performed* The start cylinder 
address is entered as decimal digits. 

endcyladr is the last cylinder address on the DASD on which the 
format function is to be performed. The end cylinder 
address is entered as decimal digits. 

TEMP indicates that the following operands identify temporary 
storage space reserved for spooling or paging activity. 

PERM defines an area that can contain the logout area, the CP 
nucleus, and space that is not used by the system but is 
available for use by virtual machine users (for exanple, 
for user minidisks) . 

TDSK defines the pooled space available for virtual machine 
users after they have logged on the VM/370 system. 

DRCT indicates that the following cylinders are reserved for 
directory files. 

ALLOCATE is a control word and may be abbreviated to its first 
letter, A. 

TEMP, PERM, TDSK, and DRCT are all functions of ALLOCATE. These 
cards can follow the ALLOCATE control statement in any sequence. Each 
card in turn overlays the cylinder table, and any space not reallocated 
remains the same. If an ALLOCATE function overlays the previous 
cylinder allotment, then the previous cylinder space allotment is 
truncated to the beginning of the next cylinder allotment. For example: 

Disk Storage 

Allocation 

1st Entry TEMP 
2nd Entry PERM 
3rd Entry TDISK 



First 


Last 


Cylinder 


Cylinder 


000 


202 


010 


050 


040 


050 



U LW^i. 



5th Entry END 
The result of this disk volume allocation is: 



Disk storage 


First 


Last 


Allocation 

DRCT 


Cylinder 
000 


Cylinder 
004 


TEMP 


005 


009 


PERM 


010 


039 


TDSK 


040 


050 


TEMP 


051 


202 



Once an ALLOCATE control statement is encountered, all cards 
following it until an END card is encountered are assumed to be part of 
a single allocation. The Format/Allocate service functions cannot be 
performed on another disk volume until the END card is encountered. 

Note: Reallocation of a directory cylinder containing an active VM/370 
directory deallocates the directory to allow a new directory to be 
written on the same cylinder. 
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I LllJt Control Statement 

The format of the LABEL control statement is: 

• 1 

I FORMAT, devadr,devtype,volser, LABEL | 

¥ h er e : 

devadr is a three-digit hexadecimal number that identifies the 
address of the device that the Format/Allocate program is 
to act upon. 

devtype is a four— or seven— character field that defines an 
approved device for the Format/Allocate program. Approved 
I device types are 2314, 2319, 3330, 3330-11, 33U0, 3340-35, 

I 3340-70, 2305-1, and 2305-2. 

volser is a one- to six-character field that represents the volume 
serial number. 

LABEL is a keyword designating the label function of the 
Format/Allocate program. 

Note: FOBMAT and LABEL are control words and may be abbreviated to F and 
L, respectively. 

Ex am£l es : 

FORMAT : 

FORMAT, 232, 3330, MYDISK, 000, 006 
FORMAT, 232, 3330, MYDISK,,, 
FORM AT, 2 32, 33 30, MYDISK,, 00 
FORMAT, 232, 3330, MYDISK, 001,, 

A LLOC ATE : 

ALLOCATE, 232, 3330, MYDISK 

TEMP, 000,050* 

PERM, 055, 060 

TDSK,100,108 

DRCT, 110, 120 

END 

LABEL : 

F, 232, 3330, MYDISK, label 



I FORMAT/ALLOCATE CONSOLE INPUT 

The Format/Allocate program can be controlled by control statements 
entered into the real or virtual console instead of by a deck of cards 
containing control statements. If the program finds no control 
statements at the card reader, it issues a prompting message to the 
console. The proper response causes the prompting message for the next 
operand to appear until the Format, Allocate, or Label function is 
completely defined; then the Format/Allocate program is executed. 
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After execution, the prompting begins again until all DASD allocation 
requirements are fulfilled. 

The sequence for console typewriter processing of the Format/Allocate 



1. Load the card reader with a loader, followed by the Format/Allocate 
deck, 

2. IPL the card reader. 

3. Respond to the first message displayed at the system console. 

U. Respond to other messages. 

Following are examples of Format/Allocate program execution under CP 
control. Figure 34 is an example of the label operation. Figure 35 is 
an example of the allocate operation, and Figure 36 of the allocate 
overlap operation. All responses are entered after the colon; after a 
function is complete, the program returns to 'ENTER "FORMAT" OR 
"ALLOCATE":' 



VM/370 FORMAT/ALLOCATE PROGRAM VERSION 2.0 

ENTER "FORMAT" OR "ALLOCATE" :f 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU):131 

ENTER DEVICE TYPE: 231U 

ENTER START CYLINDER (XXX) OR "LABEL" :1 

ENTER DEVICE LABEL:cpdsk2 



Figure 34. Using the Format Program Label Function 



ENTER "FORMAT" OR "ALLOCATE" :a 

ALLOCATE FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU):131 

ENTER DEVICE TYPE: 2314 

ENTER DEVICE LABEL: cpdsk2 

ENTER ALLOCATION DATA FOR VOLUME CPDSK2 

TYPE CYL CYL 



drct 000 001 

perm 004 008 

tdsk 100 150 

end 

ALLOCATION RESULTS 

DRCT 000 001 

TEMP 002 003 

PERM 004 008 

TEMP 009 099 

TDSK 100 150 

TEMP 151 202 

DEVICE 131 VOLUME CPDSK2 ALLOCATION ENDED 



Figure 35. Using the Format Program Allocate Function 
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ENTER "FORMAT" OR "ALLOCATE" :a 

ALLOCATE FONCTION SELECTED 

ENTER DEVICE ADDRESS (CCU):131 

ENTER DEVICE TYPE: 2314 

ENTER DEVICE LABEL: cpdsk2 

ENTER ALLOCATION DATA FOR VOLUME CPDSK2 

TYPE CYL CYL 



pern 004 004 

temp 000 010 

tdsk 000 010 

perm 010 202 

end 

ALLOCATION RESULTS 

TDSK 000 009 

PERM 010 202 

DEVICE 131 VOLUME CPDSK2 ALLOCATION ENDED 

Figure 36. Using the Foriat program Allocate Overlap Function 



I Note that before the ALLOCATE function was invoked, cylinder was 

I formatted and labeled CPDSK2. The area associated with the first three 

I 4096-byte blocks on cylinder are not used for spooling but contain 

I system information (page allocation map, label, and so on) . 



I These CP— formatted volumes can be made usable by CP in one of two 

I ways: 

I 1. They may be attached to the system by the VM/370 operator. 

I 2. Their volume serial numbers may appear in the SYSOWN macro in the 

I DMKSYS module. The CP system residence volume's serial number must 

I appear in the SYSOWN macro. 
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Appendix G: Compatibility of VM/370 with CP-67/CMS 



VM/370 and its components, the control program (CP) and the 
Conversational Monitor System (CMS) , are based on the CP-67/CMS system, 
and are designed especially for the IBM . The Dynamic Translation 
Facility on the System/370 System/370 provides the same facilities as 
did Dynamic Address Translation (DAT) on the System/360 Model 67, but 
differs in hardware design details and software implementation. 
Consequently, the CP-67/CMS system does not run on a System/370, and the 
VM/370 system does not run on the System/360 Model 67. The internal 
control block structure differs between the two systems, and user 
modifications to the CP-67/CMS system may no longer be necessary, 
desirable, or usable in the new system without some redesign effort. 

Certain commands familiar to CP-67 users are not supported in 

VM/370. The functions available under CP-67 do, however, have 

equivalents in VM/370 where appropriate. The following is a list of all 

CP-67 console functions, with operand variations, showing the 

incompatibilities with VM/370. Functions listed under CP-67 Version 3.1 

and not under VM/370 indicate that the syntax and function are 

identical. There are, of course, additional functions available with 

I the VM/370 commands. The CP and CMS commands are described in the 

i V.M/370: Command Language Guide for General Users and in the VM/370: 

I 0£§^§i2£ls Guide. 

Status: A - CP-67 Syntax accepted in VM/370 

R - CP-67 Syntax not accepted - Functionally supported by 

another command format. 
N - CP-67 Syntax not accepted - function not supported in 

VM/370. 

In Figure 37, the letter in the Status column has the following 
meanings: 

A indicates CP-67 syntax accepted in VM/370 

R indicates CP-67 syntax not accepted but the function is 
supported by a different VM/370 command 

N indicates CP-67 syntax not accepted and the function is not 
supported in VM/370. 

Whenever an R appears in the "Status" column, the VM/370 command 
that provides the same function as a former CP-67 command is shown 
in the "VM/370 Equivalent" column. 
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i status 


CP-67 Command 


VM/370 Equivalent 


1 B 1 


ACHT 1 


ACNT ALL 


i A 


iTTACH CUU TO r SYSTEM) AS fvolid ) 
\ useridj ( vaddr / 




1 A 
1 A 


BEGIN 

BEGIN hexloc 




1 A 

1 A 
1 A 


DCP hexloc 1[-hexloc2] 
DCP Lhexloc1[-hexloc2] 
DCP Thexloc1[-hexloc2] 




1 A 

1 R 


DETACH vaddr 
DETACH raddr 


DETACH raddr FROM rSYSTEM) 
1 userid/ 


1 A 


DIAL system 




1 N 

i N 


DIRECT LOCK 
DIRECT UNLOCK 




1 A 
1 A 


DISABLE line 
[DISABLE ALL 




1 A 
1 R 


DISCOHN 
DISCCNN XXX 


DISCONN HOLD 


1 A 
1 B 
i A 


DISPLAY hexloci [-hexloc2] 
IDISPLAY L[-hexloc2] 
DISPLAY Lhexloc1[-hexloc2] 


r T 

DISPLAY L0|-hexloc2| 

1 l-END 1 

L J 


1 B 
1 A 


IDISPLAY T[-hexloc2] 
DISPLAY Thexloc1[-hexloc2] 


1 r 1 

DISPLAY T0|~hexloc2| 

1 l-END 1 

L J 



Figure 37. VM/370 Compatibility with CP-67 (Part 1 of 4) 
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status 


CP-67 Command 


1 VM/370 Equivalent 








1 r T 




E 


IDISPLAY K[-hexloc2] 


DISPLAY K0|-hexloc2| 




A 


DISPLAY Khexloc1[-hexloc2] 


j {-END I 

1 




A 


IDISPLAY G[-reg2] 


1 




A 


DISPLAY Greg[-reg2] 


1 




A 


[DISPLAY Y[-reg2] 


1 




A 


DISPLAY Yreg[-rGg2] 


I 




A 


DISPLAY X[-reg2] 






A 


DISPLAY XrGg[-rGg2 3 


! 




A 


DISPLAY PSW 






A 


DMCP hexloc1[-hexloc2] 


r -1 




B 


DMCP L[-hexloc2] 


DMCP L0|-hexloc2| 




A 


DMCP Lhexloc1[-hexloc2] 


l-END 1 

L J 

r T 




B 


DMCP T[-hexloc2] 


DMCP T0|-hexloc2| 




A 


DMCP Thexloc1[-hexloc2] 


l-END 1 

L J 

• 




A 


DBAIN 






N 


DUMP 






A 


ENABLE line 






A 


ENABLE ALL 






A 


EXTEBNAL 






A 


IPL CMS 






A 


IPL devadd j 






B 


IPLSAVE CCW ! 


IPL vaddr NOCLEAB 




B 


KILL userid 


FOBCE userid 




N 


KILL 

r 1 






A 


LINK userid xxx yyy | W|[ PASS=pwd] | 

L J j 








r n 


r T 




B 


LINK userid xxx yyy |H| (NOPASS) | 


LINK userid xxx yyy |W| 






|R| 


|R| 






L J 


L J 




A 


LOCK userid fpage Ipage ! 






A 1 


LOGIN userid 






B 


LOGIN userid xxx I 


LOGON userid MASK 




A 


LOGOUT 1 






B 1 


LOGOUT XXX 


LOGOFF HOLD 





Figure 37. Compatibility of VM/370 with CP-67 (Part 2 of 4) 
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status 


CP-67 Comaand 


1 VM/370 Equivalent | 


A 


MSG userid line 




R 


jMSG CP line 


MSG OPERATOR line | 


A 


MSG AIL line 




R 


PSHRESTART 


SYSTEM RESTART | 


A 


PURGE 


READER 




A 


1 PURGE 


PRINTER 




A 


PURGE 


PUNCH 




R 


QUERY 


DEVICE ALL 


QUERY ALL | 


R 


IQUERY 


DEVICE XXX 


QUERY XXX 1 


A 


QUERY 


DUMP 




A 


IQUERY 


FILES 




A 


QUERY 


LOGMSG 




N 


QUERY 


MAX 




A 


QUERY 


NAMES 




n 


QUERY 


PORTS 




R 


QUERY 


PORTS ALL 


QUERY LINES j 


N 


QUERY 


PORTS FREE 




R 


QUERY 


PORTS XXX 


QUERY XXX 1 


A 


QUERY 


PRIORITY userid 




R 


QUERY 


Q2 


QUERY PAGING I 


A 


QUERY 


TIME 




A 


IQUERY 


userid 




A 


QUERY 


USERS 




A 


IQUERY 


VIRTUAL XXX 




A 


QUERY 


VIRTUAL CORE 


QUERY VIRTUAL STORAGE | 


A 


QUERY 


VIRTUAL ALL 




A 


READY 


XXX 




A 


REPEAT XXX y 




R 


RESET 




SYSTEM RESET | 


R 


SET ADSTOP xxxxxx 


ADSTOP XXXXXX 1 


R 


SET ADSTOP OFF 


ADSTOP OFF 1 


R 


SET APLBALL (ON \ 


TERMINAL APL fON ) | 
(OFF/ 1 






\OFF/ 


R 


SET ATTN /ON | 


TERMINAL ATTN / ON 1 | 
(OFFj 1 






(OFF / 


R 


SET CARDSAVE / ON \ 


SPOOL READER i HOLD ) j 
(NOHOLD) 1 






\OFFJ 1 


A 


SET DUMP XXX 




A 


SET f LINEDIT) ( on ) 
\ RUN / \OFF j 




A 1 


SET LOGMSG 




A 


SET LOGMSG NULL | 




A 1 


SET LOGMSG n 





Figure 37. Compatibility of VM/370 with CP-67 (Part 3 of 4) 
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status 


CP-67 Coimand 


1 VM/370 Equivalent 


1 


N 


SET MAX 


1 




A 


SET MSG |0N \ 
1 I OFF j 


! 
1 




R 
R 
R 
R 


ISET Q2 nn 

SET TRACE devtype 
ISET TRACE OFF 

SET TRACE END 


1 

SET PAGING nn 
ITRACE type dev 

TRACE type OFF 
ITRACE END 




A 


SET HNG ( ON \ 
\OFF j 






A 


SHUTDOWN 






A 


SLEEP 






A 


SPACE XXX 






R 
A 
R 


SPOOL XXX ON yyy 
SPOOL XXX CONT 
SPOOL XXX OFF 


SPOOL yyy CLASS x 
SPOOL XXX NOCONT 




A 


START XXX 






A 
A 


STCP hexloc 
STCP Shexloc 






A 

A 

A 

A 

A 1 

A 


STORE Lhexloc hexinf o. . . 

STORE Shexloc hexstring | 

STORE Greg hexinf o. . . 

STORE Yreg hexinf o... | 

STORE Xreg hexinfo... 

STORE PSW [hexinfol] hexinf o2 | 






R 


TERM XXX ! 


FLUSH XXX 




A 


UNLOCK userid fpage Ipage | 






A 

A 1 


HNG userid text | 
WNG ALL text 






R 1 


XFER XXX |T0 userid) 

(OFF / 1 


SPOOL XXX ( TO userid ) 
I OFF / 





Figure 37. Compatibility of VM/370 with CP-67 (Part ^ of 4) 
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Incompatibility Statement to CP-67/CMS Users 

Although the CMS in VM/370 is built upon CMS Version 3.1 in CP-67/CMS, 
there are five types of modifications that were made to 3.1 that affect 
the relationship between versions: 

1. Unchanged: Some commands and system functions remain unchanged; 
therefore, complete compatibility exists. 

2« Additional Functional Capability: Functional and syntactical 
enhancements are effected; but, in some cases, old keywords and 
functions are supported. 

3, Command Name Alterations: Commands have name changes, but a SYNONYM 
file may be included during nucleus system generation. 

**• Miwor^ Changes: Some keywords within a command are modified, 
deleted or added. 

5« Major Modifications: Improvements to commands and system functions 
caused complete incompatibilities in the following areas: 

• Because the CMS nucleus is significantly larger, all MODULES 
must be recreated from their object (TEXT) files using the 
6ENM0D command. 

• Because you may now have up to 10 disks, the logical directory 
identifications (filemode letters) are changed to reflect a more 
natural, easy-to-remember, search order: P, T, A, B, S, C 
becomes A, B, C, D, E, F, G, S, Y, Z — with the system disk 
being the S-disk, and the primary disk becoming the A-disk. 

• The following global changes of filetypes must be made: 

SYSIN to ASSEMBLE 
ASP360 to MACRO 

• For language processors, the DECK and NODECK options have a new 
meaning, they route the object (TEXT) file to the spooled card 
punch; the LOAD and NOLOAD options now invoke the function 
formerly performed by DECK and NODECK, and the writing of the 
TEXT file onto a CMS disk. 

• No 2311 disk support is provided for CP or CMS files. 

• In Version 1.0 the tape designations are as follows: 

TAP1 is for 181 
TAP2 is for 182 

The default for tape commands is TAP1. 
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CMS does not function on a real CPU without the control 
program. 

TXTLIB files must be recreated. 

Because many fields are changed in the CMS nucleus or 
rearranged, many of your programs that refer to these fields 
have to be reassembled with the new CMS macro libraries. 

Modules that refer to fields containing sizes, limits, and 
quantities within the CMS nucleus might have to be reassembled 
and then regenerated. 

SYSLIB MACLIB is renamed to CMSLIB MACLIB. 

All EXEC files should be checked for command name and operand 
changes, filemode usage, and so on, and changed to conform to 
VM/370 CMS^ Major changes are; 

&TYPEO0T to &CONTROL 
ePBINT to &TYPE 
6INDEX0 to SRETCODE 



• The options specified for a LOAD command do not remain in effect 
for subsequent INCLUDE commands; options are reset to default 
settings unless the SAME option is specified. 

• Filenames and filetypes must be composed entirely of alphameric 
characters. 

• If the CMS Version 1.0 system does not recognize a command name, 
the command line is automatically passed to CP. If the CMS SET 
and QUERY commands do not recognize an operand or option, the 
command line is passed to CP. This is not true for EXEC files; 
the CP command must be explicitly stated. The feature may be 
negated by entering the command: 

SET IMPCP OFF 



I VM/370 CMS SUPPORT OF CP-67/CMS COMMANDS 

ALTER Command name changed to RENAME. 

Components of the new file identifier may not be specified 

as asterisk {*) . An equal sign (=) performs the same 

function. 
NOUP option keyword changed to NOUPDIRT; NOUP is the 

abbreviation. 
Default options added: NOTYPE, UPDIRT. 

ASSEMBLE Only one file may be assembled per ASSEMBLE command. 

QEtigns_Changed : 

NODECK is the default 

DIAGINODIAG changed to TERM|NOTERM 

LTAPn not supported 

LDISK option name changed to DISK 

O£iioss_ Added : 

LOAD I NOLO AD , ALGN|NOALGN 

OSIDOS, TESTINOTJST, LINECT nn|55, 

NUMINOHDM, STMTINOSTMT 
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lill Functionally supported by SET BLIP. 

IMO ^^^ inplementecl. 

CEDIT Functionally supported by EDIT. 

CHABDEF Functionally supported by CP TERMINAL CHABDEF coimand. 

CLOSIO Functionally supported by the CP coiiands, SPOOL and CLOSE. 

CLROVER Functionally supported by SVCTRACE OFF coaimand. 

CNVT26 Functionally supported by COPYFILE command with EBCDIC 
option. 

COMBINE Functionally supported by COPYFILE. 

COMPARE Filemode required. 

NCSEQ option functionally supported by COL option. 

CPFUNCTN Command name changed to CP. 
NOMSG option not supported. 

CVTFV Functionally supported by COPYFILE. 

DEBUG No change. 

DEBUG Subcommands 

BREAK No change. 

CAN No change. 

CSN No change. 

DEF Subcommand name changed to DEFINE; DEF minimum 
truncation; no change in format. 

DUMP No change. 

GO No change. 

GPR No change. 

lEL Not supported from DEBUG. 

KX Supported by CMS command HX. 

ORIGIN No change. 

PSW No change. 

RESTART Not supported. 

RETURN No change. 

SET No change. 

STORE No change. 

TIN Not supported. 

X If symbol specified, length of field defaults to 
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DISK 



No change. 



DUMPD 



Functionally supported by DDR command. 



DUMPF 



Functionally supported by TYPE command with HEX option. 



DUMPEEST 



Functionally supported by DDR command. 



ECHO 



Functionally supported by CP command ECHO. 



EDIT 



Filename must be specified. 

Filemode may be specified. 

IRECL may be specified for a new file 



lPIT_Subcofflmands 

BACKSPACE Functionally supported by CMS command, SET 
INPUT. 

BLANK Functionally supported by OVERLAY. 

BOTTOM Bo change. 

BRIEF Function accomplished by VERIFY OFF request. 

CHANGE No change. 

DELETE /string/ is not valid as an operand. 

(DELETE * may be used to delete to end of 
file.) 

FILE Filetype and filemode may be specified. 

FIND No change. 






J. u £ u J. 



INSERT Functionally supported by INPUT request. 

LOCATE No change. 

NEXT No change. 

OVERLAY No change. 

PRINT Request name changed to TYPE. 

(TYPE * may be specified to indicate that 
typing is to continue until EOF.) 
Instead of L in second field, * is specified. 

QUIT No change. 

REPEAT Valid only for subsequent OVERLAY subcommand. 

(REPEAT * may be specified to indicate that the 
OVERLAY subcommand is to be repeated for the 
remainder of the file.) 
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RETYPE Bequest name changed to REPLACE. 

SAVE Filetype and filenode nay be specified. 

SERIAL First operand changed to 

{OFFI 'seq' (same as ID)|ON|ALL). 

TABDEF Functionally supported by CBS command SET 
IMPUT. 

TABSET No change. 

TCP Ho change. 

UP No change. 

VERIFY Operand format changed; function added. 

X No change. 

Y No change. 

ZONE No change. 

JllSJ Default option added; old format accepted. 
* * * Not supported. 

EXEC No change. 

J X 1C_C o n t r o 1_ H o r d s 

&ERROR Action does not default to 8C0NTINUE. 

8IF No change. 

&EXIT No change. 

8CUIT Functionally supported by &EXIT 0. 

&SKIP No change. 

8G0T0 EXIT not supported as operand. 

Line-number now a valid operand. 

SLOOP No change. 

&CONTINUE No change. 

&TYPEOUT Functionally supported by 6C0NTR0L control word; 
ON, NOEXEC, RESDJIE, KILL not valid. 
CMS operand added. 

r T r 1 

ION I IRESETI 
6TIBE Operands changed to I OFFI | TYPE). 

L J L J 

&SPACE No change. 

SPRINT Functionally supported by 8TYPE. 

8UPHINT Functionally supported by &BEGTYPE. 
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&PU1ICH No change. 

8DPUNCH Punctionally supported by &BEGPUNCH 

5C0MMENT Functionally supported by * card. 

&ABGS No change. 

&READ VARS operand added. 

8STACK No change. 

&BEGSTACK ALL Operand added. 

SENDSTACK Functionally supported by &END. 

&SET Not implemented. 



FILEBEF 



FORMAT 
FORTRAN 

GEN DIRT 
GENMOD 

GLOBAL 
IPL 



KB 

KT 

M 
LINEND 



Device names changed: CON - TERMINAL 

DSK - DISK 

DSK-nn - not supported 

DUMMY - no change 

PRT - PRINTER 

PUN - PUNCH 

RDR - READER 

TAPEn ~ unchanged 

BAT - not supported 

Not supported from terminal. 

All functions supported; all operands changed. 

This command is now supported by the commands F0RTG1, 
FORTHX, GOFORT, and CONVERT which invoke IBM Program 
Products. 

Target mode parameter is added. 

Incompatible; positional parameters and options changed; 
equivalent function performed. 

PRINT function removed; others compatible. 

Not explicitly supported in CMS; however, the command may be 
issued and is passed to the control program for 
processing. 

Either a device address or system name must be specified. 
Cyl-no may be specified. 

O£tions_ Added : CLEA R | NOCLE AR . 

Functionally supported by the CP command TERMINAL LINESIZE 
nn. 

Command name changed to HO. 

Command name changed to HT. 

Command name changed to HX. 

Functionally supported by the CP command TERMINAL LINEND. 
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LISTF 



Command name changed to LISTFILE; LISTF accepted. 

Q£ii5fi_C hanges : 

SORT- Option not implemented, 

ITEM- Option not implemented; ALLOC option produces 

both logical records and blocks, 
NAME- Option name changed to FHAME, 
TYPE- Option name changed to PTYPE, 
MODE- Option name changed to FMODE, 
EEC- Supported by ALLOC option, 
DATE- Produces mm/dd/yy hh:mm, 
YEAR- Not implemented; functionally supported 

by DATE option. 
TIME- Not implemented; functionally supported 

by DATE option. 
LABEL and FORMAT options added. 
APPEND option added. 
HEADERINOHEADER option added. 



LOAD 



OEiio£_C han^es : 
SLCxxxxxx— 
SLC12000- 
SINV- 
PINV- 
SREP- 
PREP- 
SLIBE- 
SAUTO- 
XEQ- 
NOXEQ- 



option changed to ORIGIN xxxxxx. 

default changed to first available location, 

option name changed to NOINV. 

option name changed to INV. 

option name changed to NOREP. 

option name changed to REP. 

option name changed to NOLIBE. 

option name changed to NOAUTO. 

option name changed to START. 

option not supported. 



Options Added : RESET. 



TXTLIB files may 
but must have 
command. 



no longer be specified in a LOAD command, 
been previously specified by a GLOBAL 



LOADMOD 



Filetype must be specified if filemode is given. 



LOGIN 



Functionally supported by LOGON and ACCESS commands. 
Comma between mode and extdisk replaced with slash (/) ; 
extdisk optional. 

0£ tions : 

BOPROF-option supported. 
NOTYPE-option not supported. 
NO-UFD-option name changed to ERASE. 



LOGOUT 



Functionally supported by CP command LOGOFF. 



MAPPRT 



Functionally supported by CMS commands TYPE or PRINT, 



MODMAP 



No change. 



OZHjOI read Functionally supported by READCARD command, 
OZIilM PRINT Functionally supported by PRINT command. 
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OIZLOl PRINTCC Functionally supported by PRIUT command. 

OFFLINE PRINTUPC Functionally supported by PRINT command. 

OFFLINE PUNCH Functionally supported by PUNCH command. 

OFFLINE PUNCHCC Functionally supported by PUNCH command. 

OFFLINE PUNCHDT Functionally supported by PUNCH command. 



OSTAPE 



Command name Changed to TAPPDS. 



PLI 



This command is now supported by the command PLIOPT which 
invokes an IBM Program Product. 



PRINTF Command name changed to TYPE. 
Filemode may be specified. 
n3 functionally supported by COL option, 

Options added: HEX, MEMBER. 



RELEASE DET option not implemented although functionally supported 
by the CP command DETACH. 



REUSE 



Command name changed to INCLUDE. 
Option differences are the same as for LOAD. 

TXTLIB files may no longer be specified in the command; but 
must have been previously specified by a GLOBAL command. 



RT 



No change. 



SCRIPT Files may be processed by SCRIPT/370, an IBM user-installed 
program. 

SETERR Functionally supported by SVCTRACE ON. 
SETOVER Functionally supported by SVCTRACE ON. 



SNOBCL 



Not implemented. 



SORT 



Filemode must be specified for both input and output files, 



SPLIT 



Functionally supported by COPYFILE command. 



START 



(NO) operand not valid. 



STAT 



Functionally supported by QUERY command, 



STATE 



No change. 
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SYN Comaand naie changed to SYNONYM; SYN ■ininuB truncation. 
Filetype must be SYNONYM. 

Options : 

SYNONYM coanand with P and PDSER options is functionally 
supported by QUERY SYNONYM. 

TAPE TAPn may also be specified by a virtual address. 

"n" options after SCAN, SKIP, SLOAD, replaced by 'EOF n'. 

OEtions_ Added: 7TRACKI 9TRACK, DEN, TRTCH. 

Iunctions_Ad^ed: MODESET, BSF, BSR, ERG, FSF, FSR, RON, 
REN. 

TAPE DUMP 0£ t io ns_added : WTMINOWTM, NOPRINT (PRINT |TERM | DISK. 

TAPE LOAD Functionally supported by TAPE LOAD EOFn. 
File identifiers may be specified. 

OEtions_ Added: NOPRINTj PRINT | TERM | DISK, 
EOFn|EOT|EOFl. 

TAPE SCAN Filename and filetype may be specified. 

Functionally supported by TAPE SCAN (EOF n) . 

Q£tions_added : NOPRINT | PRINT | TERM | DISK , 
EOFnlEOTIEOFJ- 

TAPE SKIP Comments same as for TAPE SCAN. 

TAPE SLOAD Functionally supported by TAPE LOAD fn ft. 
Filemode may be specified. 

142110 Functionally supported by TAPE. 

TAPPps Default filename is TAPPDS for NOPDS option. 
Default filetype is CMSUT1 . 

NPDS — option name changed to NOPDS- 
NCOLI - option name changed to NOCOLI. 
TAPx - default is TAP1. 
NEND - option name changed to NOEND. 
NMAXTEN - option name changed to NOMAXTEN. 

TAPRINT Functionally supported by MOVEFILE command. 

TPCOPY Functionally supported by MOVEFILE command. 

miill PRINT and LIST functions supported by MAP function. 

UPDATE 0Eii:On_C haiiSes : 

P - option name changed to REP. 

Default options added NOREP, N0SEQ8, NOINC. 

USE Functionally supported by INCLUDE command with the SAME 
option. See discussion of REUSE compatibility. 
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VSET Command name changed to SET. 

Functions : 

BLIP OM may be specified to return to default 
CHARDEF Functionally supported by CP 

command TIBMIHAL UCHARDIL JLIHIDEL j ESCAPE } 
IMPEX No change. 
LDRTBLS No change. 
LINEND Functionally supported by CP command TERMINAL 

LINEND. 
RDYMSG ON I OFF changed to LMSG|SMSG. 
REDTYPE No change. 
RELPAGE No change. 

lU net ions_added : INPUT, OUTPUT, ABBREV, IMPCP. 

WRTAPE Functionally supported by TAPE command or MOVEFILE commands 

^ Command name changed to RUN. 

Filetype and filemode may be specified. 

Files may also have filetypes in addition to EXEC, MODULE, 
and TEXT of those used by the language processors for 
input. 



CPr67/CMS MACROS AND FUNCTIONS AND CORRESPONDING CMS MACROS 

The list below shows VM/370 CMS macros that correspond to CP-67/CMS 
macros and functions. The CP-67/CMS functions have no structural 
equivalent in VH/370 CHS, but in most cases the function is available 
via a VM/370 CMS macro. If you need information on how to build a 
parameter list which can be scanned properly by VM/370 CMS, refer to the 

I VW/370: System Programmer's Guide or VM/320 Command Language Guide for 

I Gene ra l Users. 



CP-67/CMS 


VM/370 




CP-67 


VM/370 Macros 


Macros 


Eguivalent 




Functions 


Equivalent 


CKEOF 


Not Availa 


ble 


DEBDUMP 


Not Available 


CMSREG 


BEGEQU 




ERASE 


FSERASE* 


CMSYSREF 


Not Availa 


ble 


FILEDEF 


1 


ERASE 


FSERASi 




FINIS 


FSCLOSE 


FCB 


No Change 




HNDINT 


HNDINTi 


FINIS 


FSCLOSE 




HNDSVC 


HNDSVCi 


FSTB 


No Change 




POINT 


FSCB, FSREAD, FSWBITE, 


RDBUF 


FSREAD 






FSOPEN 


SETUP 


FSOPEN 




PRINTR 


PRINTL 


STATE 


FSSTATE 




RDBUF 


FSREAD 


TYPE 


WRTERM 




STATE 


FSSTATE 


TYPIN 


RDTERM 




STRINIT 


No Change 


WRBUF 


FSHRITE 




TAPEIO 


RDTAPE, WRTAPE, TAPECTL* 


ATTN 


No Change 




TRAP 


HNDEXT 


CARDIO 


PUNCH, RDCARD 


TYPE 


WRTERM* 


CLOSIO 


1 




TYPLIN 


WRTERM 


CONWAIT 


HAITT 




WAIT 


WAITD 


CPFUNCTN 


1 




WAITRD 
WRBUF 


RDTERM 
FSWRITE 



'See the VM/370 System Proc|rammerJ[^s Guide for information on how to call 
a command from a program. 
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I Appendix H: Creating a 3340 System Residence Volume from a Current 2314 

or 3330 System Residence Volume and the PLC Tape 



I VM/370 strongly recommends that you generate the 3340 system residence 

I volume from the 3340 starter system. The process of generating a 3340 

I system residence volume from the PLC tape and a Release 2 2314 or 3330 

I system residence volume is complex and restricting; it requires that you 

I generate the CP and CMS nucleus twice. However^ you can generate a 3340 

I system residence volume without using the 3340 starter system. The 

I procedure that follows is one way to do it. You should evaluate the 

I usefulness of the following procedure for your installation before using 

I it. 

i Before you perform the following procedure, be sure that you have: 

I • The PLC tape. 

I • A Release 2 2314/3330 system residence volume. 

I • A Release 2 2314/3330 system residence volume (CPV2L0) which contains 

I the minidisk areas for updating CP and CMS. These minidisks, 190, 

I 191, 194, and 199, belong to the MAINT virtual machine. 

I • Two 3340 disks. 

I Also, you need all of the facilities of VM/370 normally required to 

I update or generate VM/370. 

I The following procedure assumes your current system residence volume 

I is labeled VMREL2 and the starter system volume (CPV2L0) is set up 

I according to the entries supplied with the Release 2 starter system 

I directories. 



I STEP J. I PL CMS 

I Log on the software system support virtual machine and IPL CMS. 

I logon maint 
I ipl 190 



I STEP 2. LOAD NEW CP MACRO LIBRARY 

I Mount the PLC tape and attach it to MAINT as 181. Assuming the PLC tape 
I is at real address 280, you enter: 

I attach 280 to maint as 181 

I Forward space the PLC tape to the DMKMAC MACLIB file and load that file 
I onto the CP staging area minidisk. 

I access 194 a 

I tape rew 

I tape fsf n 

I tape load 
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I STEP 3. UPDATE THE REAL I/O COMFIGORATIOH (DMKRIO) 111:1 

I Edit the DMKRIO ASSEMBLE file and add RDEVICE and HCTLONIT macros to 

I define the 3340 disks you wish to add to your configuration. Because 

I 3340 disks are now supported by VM/370, omit the CLASS=DASD operand. 

I Use the VHFASH EXEC procedure to assemble the updated DHKRIO ASSEHBLE 

I file: 

I vmfasm dmkrio dmkr20 



I STEP i' UPDATE CP AMD CMS WITH THE PLC CHANGES 

I YOU must rewind the PLC tape and invoke the VMFBLD EXEC procedure to 

I apply the PLC updates to CP and CMS. 

I First, rewind the tape and load VMFBLD. 

I access 191 a 
I tape rew 
I tape load 

I Next, invoke VMFBLD to build a new CP nucleus. Reply to the 

I prompting messages as shown: 

I Access 191 c 

I vmfbld cp 

I ENTER CP STAGING AREA DISK ADDRESS: 

I 194 

I ARE YOU A NEW USER? — RESPOND (YESjNO) 

I no 

I GENERATE AN IPL'ABLE SYSTEM TAPE? — RESPOND (YES|NO) 

I no 

I WRITE THE NUCLEUS TO THE SYSTEM DISK? — RESPOND (YES|NO) 

I yes 

I VMFBLD builds and loads the CP nucleus and instructs you to shutdown and 

i IPL the new system. If you are building a CP nucleus with a 

I virtual=real area, see the "Using the VMFBLD EXEC Procedure to Build a 

I New Nucleus" section of Part 6 for special considerations and operating 

I procedures. 

I After you IPL the new system, log on as MAINT, and IPL CMS, rewind 

I the PLC tape and invoke VMFBLD to update CMS. 

I logon maint 

I attach 280 to maint as 181 

I ipl 190 

I access 191 a 

i tape rew 

I tape load 

I access 191 c 

I vmfbld cms 

I ENTER CMS SYSTEM DISK ADDRESS: 

I 190 

I Respond to the prompting messages as you normally do when you apply PLC 

I updates. 
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I STEP 5. FORMAT, LABEL, AND ALLOCATE THE 3340 VOLUMES 

You Bust format, allocate, and label two 3340 volumes: one volume to be 
the system residence volume (VMREL2) and one volume to contain the 
required minidisJcs (CPV2I0) * 

Mount, vary online (if necessary) , and attach the future VMREL2 3340 
disk to MAIHT: 

vary online raddr 

attach cuu to maint as 341 

Punch a copy of the Format/Allocate program. You must be sure to use a 
copy of Format/Allocate from the VM/370 system you just updated with the 
PLC tape because the PLC tape contains the 3340 support. Issue the 
following commands to punch a copy of the Format/Allocate program: 

close punch 

close reader 

purge reader all 

access 190 b/a 

spool OOd to * 

punch ipl fmt (noheader 

ipl OOc 

Next, format, label, and allocate the 3340 disk that is to be the system 
residence disk. Format the 3340 disk exactly as you would have if you 
used the 3340 starter system generation procedure. 

In the following example, the responses (format, 341, 3340-35, 000, 
348 and VMREL2) format the 3340 disk at address 341 and label it VMREL2. 
The values you should specify for a 3340 Model 70 are shown in 
parentheses. 

VM/370 FORMAT/ALLOCATE PROGRAM VERSION 2.0 

ENTER FORMAT OR ALLOCATE: format 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 341 

ENTER DEVICE TYPE: 3340-35 (or, 3340-70) 

ENTER START CYLINDER (XXX) OR "LABEL": 000 

ENTER END CYLINDER (XXX) ; 348 (or, 697) 

ENTER DEVICE LABEL: vmrel2 

FORMAT STARTED 

FORMAT DONE 

000 PAGE RECORDS FLAGGED 

Now that the system residence volume is formatted and labeled, you must 
allocate the disk space. In the following example, the space on the 
3340 disk at address 341, with the label VMREL2, is allocated (11 
cylinders of permanent space, 5 cylinders of directory, 310 cylinders of 
temporary space, and 23 cylinders of TDSK space) : 

ENTER FORMAT OR ALLOCATE: allocate 

ALLOCATE FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 341 

ENTER DEVICE TYPE: 3340-35 (or, 3340-70) 

ENTER DEVICE LABEL: vmrel2 

ENTER ALLOCATION DATA FOR VOLUME VMREL2 

TYPE CYL CYL 



perm 000 010 
drct Oil 015 
temp 016 325 
tdsk 326 348 
end 
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ALLOCATION RESULTS 

PERM 000 010 

DRCT Oil 015 

TEMP 016 325 

TDSK 326 348 

DEVICE 341 VOLUME VMREL2 ALLOCATION ENDED 

If your system residence voluae is a 3340 Model 70, the allocation 
results messages show the unused cylinders (349-697) as temporary 
space. 

Next, you must format, label, and allocate a 3340 to contain the 
required minidisks. This is the volume that is normally labeled CPV2L0. 
At this time that volume must be labeled something other than CPV2L0 and 
allocated as permanent space. Later the label will be changed to 
CPV2L0. In the following example the volume at address 340 is labeled 
TCPVOL and allocated as permanent space: 

ENTER FORMAT OR ALLOCATE: format 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCU) : 340 

ENTER DEVICE TYPE: 3340-35 (or, 3340-70) 

ENTER START CYLINDER (XXX) OR "LABEL": 000 

ENTER END CYLINDER: 348 (or, 697) 

ENTER DEVICE LABEL: tcpvol 

FORMAT STARTED 

FORMAT DONE 

000 PAGE RECORDS FLAGGED 

ENTER FORMAT OR ALLOCATE: allocate 

ALLOCATION FUNCTION SELECTEE 

ENTER DEVICE ADDRESS (CCU) : 340 

ENTER DEVICE TYPE: 3340-35 (or, 3340-70) 

ENTER DEVICE LABEL: tcpvol 

ENTER ALLOCATION DATA FOR VOLUME TCPVOL 

TYPE CYL CYL 



perm 000 348 (or, perm 000 697) 

end 

ALLOCATION RESULTS 

PERM 000 348 

DEVICE 340 VOLUME TCPVOL ALLOCATION ENDED 

ENTER FORMAT OR ALLOCATE: 

Enter CP mode and detach the volumes you just formattted and allocated. 
Then IPL CMS. 

detach 340 
detach 341 
ipl 190 



I STEP 6. UPDATE THE CURRENT VM/370 DIRECTORY 

Edit your current VM/370 Directory program control statements and add 
the following control statements to the software support virtual machine 
(MAINT) : 

MDISK 290 3340 048 203 TCPVOL MR READ 

MDISK 291 3340 027 014 TCPVOL WR 

MDISK 294 3340 251 098 TCPVOL MR 

MDISK 299 3340 046 002 TCPVOL WR 

MDISK 341 3340 000 348 VMREL2 MW 

MDISK 340 3340 000 001 TCPVOL MH 
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The first five minidisk areas just defined correspond to those defined 
during the 3340 starter system generation procedure; they are identical 
except for virtual device addresses and volume labels. The entries just 
defined are on virtual channel 2; the starter system procedure places 
the minidisks on virtual channel 1. After the minidisks are moved from 
the 23 14 ■'3330 volume to the 3340 volume the 3340 minidisk address is 
changed to virtual channel 1. At this time the virtual device addresses 
must be different. 

The MAINT virtual machine also has the first cylinder of the TCPVOL 
volume defined so it can change the label to CPV2L0 after the complete 
3340 system is built. MAINT has the 3340 VMREL2 volume defined so it 
can generate a 3340 system residence and load the 3340 VM/370 directory 
onto it. 

After you update the VM/370 Directory program control statements, 
load the directory on the current system (2314/3330). Issue the CMS 

AJ^ i\£b\^ X \^ v/ ill iU d Ai u, wv/ ji.\^€Lu. o u^ vIXx. o^^ w> \.^^ j • 

direct filename 

You must log off and log on again to make the new MAINT directory 
entries effective. Before you log off, attach the 3340 volume (TCPVOL) 
that is to contain the minidisks to the VM/370 system. 

attach 340 to system as tcpvol 
logoff 



STEP 7. FORMAT MINIDISK AREAS 

Log on again as MAINT, IPL CMS, and format the minidisk areas so that 
they can be used with CMS. 

logon maint 
ipl 190 

MAINT now has access to the minidisks on the 2314/3330 volume (addresses 
190, 191, 194, and 199) and access to the minidisk areas to be built on 

uut; JJHV7 vuxuiue (auuj. «£>£>«£> £.i\} f ^7 1, £.•3^1 a iiu z:??;. xv^u uiuou j.ijj.uai. 

290, 291, 294, and 299. Be careful not to format 190, 191, 194, and 
199, as they are the minidisks that must be copied to the 3340 volume. 

access (nodisk 
format 291 a 
format 294 a 
format 299 a 
format 290 a 

The 290 minidisk eventually becomes the CMS system disk on the TCPVOL 
3340 volume. You must invoke FORMAT with the recompute option to make 
the last two cylinders (which will contain the CMS nucleus) unavailable 
to the CMS file system. 

format 290 a 201 (recomp 
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I STEP 8. COPY THE MINIDISKS 

Copy all the data on MAINT's 190, 191, 194, and 199 minidisks to 290, 
291, 294, and 299 minidisks. Issue the following commands: 

access 290 a 
access 190 b 
copyfile * * b = = a (replace 

Repeat the preceding three commands for each minidisk you want copied 
(191 to 291, 194 to 294, and 199 to 299). 

After all the minidisks are copied to the 3340 volume, release the 
2314/3330 minidisks, detach the 2314/3330 minidisks, and redefine the 
virtual addresses. However, do not release or detach the 2314/3330 CMS 
system disk yet. Issue the following commands: 

release 191 
release 194 
release 199 
detach 191 
detach 194 
detach 199 
define 291 as 191 
define 294 as 194 
define 299 as 199 

At this time all the data is copied onto TCPVOL. The MAINT virtual 
machine owns the areas on TCPVOL (191, 194, and 199) that it normally 
would own on CPV2L0 at this point in the 3340 starter system generation 
procedure. However, the CMS system disk is still on the 2314/3330 
volume and 290 is not yet redefined as 190. This change is made when 
CMS is generated. 



STEP 9. UPDATE AND ASSEMBLE THE CP SYSTEM CONTROL (DMKSYS) MP SYSTEM 
NAME TABLE (DMKSNT) FILES 

I Access the CP source disk (194) . 

I access 194 a 

I Edit the DMKSYS ASSEMBLE file and change the macros to support 3340 
I disks according to your planned configuration. Also, update the DMKSNT 
I ASSEMBLE file if you wish to save any systems on a 3340 disk. Then 
I assemble the updated files: 

I vmfasm dmksys dmkr20 
I vmfasm dmksnt dmkr20 



I STEP 10. UPDATE THE VM^370 DIRECTORY AND LOAD IT ON A 3340 VOLUME 

I Change the VM/370 directory as follows: 

I • Change the DIRECTORY control statement, specifying 3340 as the device 
I type. 

I • Replace the current description of the MAINT virtual machine with a 
I copy of the MAINT virtual machine that supports a 3340 system. 
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I Your entry for the MAINT virtual machine should be: 

I USER HAIBT CPCMS 16M BCEG 

I ACCOUNT ACT3 MAINT 

t OPTION ECHODE REALTIHER 

! CONSOLE 009 3215 

i SPOOL OOC 2540 READER A 

I SPOOL OOD 2540 PUNCH A 

I SPOOL OOE 1403 A 

I MDISK 341 3340 000 348 VMREL2 MH 

I MDISK 190 3340 048 203 CPV2L0 MR READ 

I MDISK 191 3340 027 014 CPV2L0 MR READ 

I MDISK 194 3340 251 093 CPV2L0 MR READ 

I MDISK 199 3340 046 002 CPV2L0 MR READ 

I Now, using the Directory program control statements you just coded, 

I invoke the Directory program and write the new VM/370 directory on the 

! 3340 disk, 

i direct filename 

I where filename is the name of your modified directory. 



I STEP XX. GENERATE A NEW CP NUCLEUS ON A 3340 VOLUME 

I The GENERATE EXEC procedure requires a scratch tape mounted and ready at 
I virtual address 182. It writes the CP nucleus on this tape. Invoke the 
I GENERATE EXEC procedure to build and load the new CP nucleus. 

I attach cuu to maint as 182 
I generate cp nucleus 

I Instructions for using the GENERATE EXEC procedure are in the "Using the 
I GENERATE EXEC Procedure to Generate a New CP or CMS Nucleus" section of 
I Part 6. 



i STEP 12. GENERATE A NEH CMS NUCLEUS OH A 3340 VOLUME 

IPL CMS and invoke the GENERATE EXEC procedure to generate a new CMS 
nucleus. 

ipl 190 

generate cms nucleus (noload 

The NOLOAD option indicates that the loadable copy of the CMS nucleus is 
to be placed in the virtual card reader. 

When the GENERATE EXEC procedure completes its processing, enter CP 
mode, detach both the 2314/3330 and the 3340 CMS system disks, link to 
the 3340 CMS system disk as 190, and IPL CMS to generate the new CMS 
nucleus on the 3340 disk (TCPVOL) . 

detach 190 
detach 290 
link * 290 190 
ipl 00c 
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I Respond to the following prompting messages as shown: 

DMSI1II606B SYSTEM DISK ADDRESS = 190 
DMSINI615R Y-DISK ADDRESS = 1 9e 
DHSIHI607R REWRITE THE NDCLEOS? yes 
DMSINI608R IPL DEVICE ADDRESS = 190 
DMSIHI609R HOCLEUS CYL ADDRESS = 201 
DMSINI610R ALSO IPJ. CYLINDER 0? yes 
DHSINI611R VERSIOH IDENTIFICATION = 
DHSINI612R INSTALLATION HEADING = 
CMS VERSION 2.0 - mm/dd/yy hh:mm 

ipl 190 

Then generate the CPEREP and ASSEMBLE modules, creating the 
corresponding auxiliary directories. 

access 190 a 
cmsgend cperep 
asmgend 



I STEP 13. CHANGE THE LABEL OP THE 3340 DISK LABELED TCP VOL 

Invoke the Format/Allocate program again to change the label of the 3340 
disk containing the minidisks from TCPVOL to CPV2L0. 

VM/370 FORMAT/ALLOCATE PROGRAM VERSION 2.0 

ENTER FORMAT or ALLOCATE: format 

FORMAT FUNCTION SELECTED 

ENTER DEVICE ADDRESS (CCD) : 340 

ENTER DEVICE TYPE: 3340-35 (or, 3340-70) 

ENTER START CYLINDER (XXX) OR "LABEL": label 

ENTER DEVICE LABEL: Cpv210 

LABEL IS NOW CPV2L0 

At this time you have generated CP and CMS on a 3340 disk and copied the 
minidisks that are needed to support VM/370 to a 3340 disk. The updated 
CP system control (DMKSYS) and system name table (DMKSNT) files are 
included in the new CP nucleus and the updated VM/370 is on the 3340 
system residence volume. 

The 2314/3330 is still intact and updated to the latest PLC level. 
It is recommended that the VM/370 directory entry for MAINT on the 
2314/3330 system be left in its updated form. If you do leave the 
updates in the 2314/3330 directory, you can build all or part of a 3340 
system again. 

After all the spool files on the system are processed, shutdown and 
IPL the new 3340 system residence volume and execute the Installation 
Verification Procedure (IVP) . 

At this time the named systems, such as CHS, can be saved. 

logon maint 
ipl 190 
savesys cms 
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Appendix I: VM/370 Restrictions 



I A virtual machine created by VM/370 is capable of running an IBM 
I System/360 or System/370 operating system as long as certain VM/370 
I restrictions are not violated. Virtual machine restrictions and certain 
I execution characteristics are stated in this chapter. 



PIOmCALLY MODIFIED CHANNEL PROGRAMS 

In general, virtual machines may not execute channel programs that are 
dynamically modified (that is, channel programs that are changed between 
the time the START I/O (SIO) is issued and the end of the input/output 
occurs, either by the channel program itself or by the CPU) . However, 
some dynamically modified channel programs are given special handling by 
CP: specifically, those generated by the Indexed Seguential Access 
Method (ISAM) running under OS/PCP, OS/MFT, and OS/MVT; those generated 
by ISAM running in an OS/VS virtual=real partition; and those generated 
by the OS/VS Telecommunications Access Method (TCAM) Level 5, with the 
VM/370 option. 

The self-modifying channel programs that ISAM generates for some of 
its operations receive special handling if VM/370 is generated with the 
ISAM option and if the virtual machine using ISAM has that option 
specified in its VM/370 directory entry. There is no such restriction 
for DOS ISAM, or for ISAM if it is running in an OS/VS virtual=virtual 
partition. If ISAM is to run in an OS/VS virtual=real partition, you 
must specify the ISAM option in the VM/370 directory entry for the OS/VS 
virtual machine. 

Virtual machines using OS/VS TCAM (Level 5, generated or invoked with 
the VM/370 option) issue a DIAGNOSE instruction when the channel program 
is modified. This instruction causes CP to reflect the change in the 
virtual CCW string to the real CCH string being executed by the channel. 
CP is then able to execute the dynamically modified channel program 
properly. 

The restriction against dynamically modified channel programs does 
not apply if the virtual machine has the virtual=real performance option 
and the NOTRANS option has been set on. 

MINIDISK RESTRICTIONS 

The following restrictions exist for minidisks: 

1. In the case of Read Home Address with the skip bit off, VM/370 
modifies the home address data in user storage at the completion of 
the channel program because the addresses must be converted for 
minidisks; therefore, the data buffer area may not be dynamically 
modified during the input/output operation. 

2. On a minidisk, if a CCW string uses multitrack search on 
input/output operations, subseguent operations to that disk must 
have preceding seeks or continue to use multitrack operations. 
There is no restriction for dedicated disks. 

3. OS/PCP, MET, and MVT ISAM may be used with a minidisk only if the 
minidisk is located at the beginning of the physical disk (that is. 
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at cylinder zero) . There is no such restriction for DOS or OS/VS 
ISAM. 

t\. VM/370 does not return an end of cylinder condition to a virtual 
machine that has a virtual 2311 napped to the top half (that is, 
tracks through 9) of 2314 or 2319 cylinders. 

5. If the user's channel program (CCHs) for a minidisk do not perform 
a Seek operation, then to prevent accidental accessing, 7M/370 
inserts a positioning Seek operation into the user's CCWs. Thus, 
certain channel programs may generate a condition code (CC) of zero 
on a SIO instead of an expected CC of one, which is reflected to 
the virtual machine. The final status is reflected to the virtual 
machine as an interrupt. 

6. DASD channel programs directed to minidisks on 3330 or 33U0 devices 
may give different results than on dedicated drives if the channel 
program includes multiple-track operations and depends on a Search 
ID High or a Search ID High or Equal to terminate the program. 
This is because the record count fields on the 3330 and 3340 must 
contain the real cylinder number of the track on which they reside; 
therefore, a Search ID High based on a low virtual cylinder number 
may terminate prematurely if a real record is encountered. This 
restriction does not apply to minidisks with a relocation factor of 
zero. This restriction does apply to minidisks with a VTOC greater 
than one track that are used with OS (Release 20.6 and later) or 
OS/VS (any release) , since the VTOC Locate function uses a Search 
ID High to stop at the end of the VTOC. 

Note; If the 'E' byte of 'CCBHR' is equal to zero at the time a 
virtual Start I/O is issued, but the 'CCHHR' field is read in 
dynamically by the channel program before the SEARCH ID CCH is 
executed, then the real SEARCH ID CCH uses the relocated 'CCHHR' 
field instead of the 'CCHHR' field that was dynamically read in. 
This causes erroneous results. To avoid this problem, the virtual 
machine should not default the'R' byte of 'CCHHR' to binary zero if 
the search arguments are to be read in dynamically and a SEARCH ID 
on Record RO is not intended. 

I 7. The IBCDASDI program cannot assign alternate tracks for a 3330. 



I TIMIHG DEPEHDESCIES 

Timing dependencies in input/output devices or programming do not 
function consistently under VM/370: 

1. The following telecommunication access methods (or the designated 
option) violate the restriction on timing dependency by using 
program-controlled interrupt techniques and/or the restriction on 
dynamically modified channel programs: 

• OS Basic Telecommunications Access Method (BTAM) with the 
dynamic buffering option. 

• OS Queued Telecommunications Access Method (QTAM) . 

• DOS Queued Telecommunications Access Method (QTAM) . 

• OS Telecommunications Access Method (TCAM) . 

• OS/VS Telecommunications Access Method (TCAM) Level 4 or 
earlier, and Level 5 if TCAM is not generated or invoked with 
the VM/370 option. 
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I These access methods nay run in a virtual=real Machine with CCH 

I translation suppressed by the SET NOTRANS ON command. (OS BTAM can 

I be generated without dynamic buffering, in which case no virtual 

I machine execution violations occur. However, the BTAM reset poll 

I macro will not execute under 7M/370 if issued from third level 

I storage. For example, a reset poll macro has a NOP effect if 

I executed from a virtual=virtual storage under VS1 which is running 

I under VM/370.) 

I 2. Programming that makes use of the PCI channel interrupt for channel 

I program modification or processor signalling must be written so 

I that processing can continue normally if the PCI is not recognized 

I until I/O completion or if the modifications performed are not 

i executed by the channel. 

I 3. Devices that expect a response to an interrupt within a fixed 

I period of time may nat function correctly because of execution 

I delays caused by normal VM/370 system processing. An example of 

I such a device is the IBM 1419 Magnetic Character Reader. 

I 4. The operation of a virtual block multiplexer channel is timing 

I dependent. For this reason, the channel appears available to the 

I virtual machine operating system, and channel available interrupts 

I are not observed. However, operations on virtual block-multiplexing 

I devices should use the available features like Rotational Position 

I Sensing to enhance utilization of the real channels. 



I CPU MODEL-DEPENDENT FUNCTIONS 

I On the System/370 Model 158 only, the Virtual Machine Assist feature 

I cannot operate concurrently with the 7070/7074 compatibility feature 

I (Feature #7117) . 

I Programs written for CPU model-dependent functions may not execute 

I properly in the virtual machine under VM/370. The following points 

I should be noted: 

I 1. Programs written to examine the machine logout area do not have 

I meaningful data since VM/370 does not reflect the machine logout 

I data to a virtual machine. 

I 2. Programs written to obtain CPU identification (via the Store CPU ID 

I instruction, STIDP) receive the real machine value. When the STIDP 

I instruction is issued by a virtual machine, the version code 

I contains the value 256 in hexadecimal ("FF") to represent a virtual 

I machine. 

I 3. Programs written to obtain channel identification (via the Store 

I Channel ID instruction, STIDC) receive information from the virtual 

I channel block. Only the virtual channel type is reflected; the 

I other fields contain zeroes. 

I 4. No simulation of other CPU models is attempted by VM/370. 



I VI RTUAL MACHINE CHARACTERISTICS 

I Other characteristics that exist for a virtual machine under VH/370 are 
I as follows: 
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1. If the virtual=real option is selected for a virtual machine, 
input/output operations specifying data transfer into or out of the 
virtual nachine's page zero, or into or out of storage locations 
whose addresses are greater than the storage allocated by the 
virtual=real option, must not occur. The storage-protect-key 
mechanism of the IBM System/370 CPU and channels operates in these 
situations but is unable to provide predictable protection to other 
virtual machines. In addition, violation of this restriction may 
compromise the integrity of the system. The results are 
unpredictable. 

2. VH/370 has no multiple path support and, hence, does not take 
advantage of the two-channel switch. However, a two-channel switch 
can be used between the IBH System/370 running a virtual machine 
under VM/370 and another CPU. 

3. The DIAGMOSE instruction cannot be issued by the virtual machine 
for its normal function. VM/370 uses this instruction to allow the 
virtual machine to communicate system services requests. The 
Diagnose interface requires the operand storage addresses passed to 
it to be real to the virtual machine issuing the DIAGNOSE 
instruction. For more information about the DIAGNOSE instruction in 
a virtual machine, see the yM/370; System Programmer's Guide. 

H, A control unit normally never appears busy to a virtual machine. 
An exception exists when a forward space file or backward space 
file command is executed for a tape drive. Subsequent I/O 
operations to the same virtual control unit result in a control 
unit busy condition until the forward space file or backward space 
file command completes. If the real tape control unit is shared by 
more than one virtual machine, a control unit busy condition is 
reflected only to the virtual machine executing the forward space 
file or backward space file command. Hhen a virtual machine 
attempts an I/O operation to a device for which its real control 
unit is busy, the virtual machine is placed in I/O wait 
(non-dispatchable) until the real control unit is available. If 
the virtual machine executed a SIOF instruction (rather than SIO) 
and was enabled for block-multiplexing, it is not placed in I/O 
wait for the above condition. 

5. The number of pages used for input/output must not exceed the total 
number of user pages available in real storage; violation of this 
restriction causes the real computing system to be put into an 
enabled wait state. 

6. The CP IPL command cannot simulate self -modifying IPL sequences off 
dedicated unit record devices or certain self- modifying IPL 
sequences off tape devices. 

7. The VM/370 spooling facilities do not support punch-feed-read, 
stacker selection, or column binary operations. Detection of 
carriage control channels is supported for a virtual 3211 only. 

8. VM/370 does not support count control on the virtual 1052 
operator's console. 

9. Programs that use the integrated emulators function only if the 
real computing system has the appropriate compatibility feature. 
VM/370 does not attempt simulation. The DOS emulators are not 
supported. 

10. The READ DIRECT and WRITE DIRECT instructions are not supported for 
a virtual machine. 

11. The System/370 SET CLOCK instruction cannot be simulated and, 
hence, is ignored if issued by a virtual machine. The System/370 
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STORE CLOCK instruction is a nonprivileged instruction and cannot 
be trapped by VM/370; it provides the true TOD clock value from the 
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12. The 1050/1052 Model 2 Data Communication System is supported only 
as a keyboard operator's console. Card reading, paper tape I/O, 
and other modes of operation are not recognized as unigue, and 
hence may not work properly. This restriction applies only when 
the 1050 system is used as a virtual machine operator's console. 
It does not apply when the 1050 system is attached to a virtual 
machine via a virtual 2701, 2702, or 2703 line. 

13. The pseudo-timer (usually device address OFF, device type TIMER) 
does not return an interrupt from a Start I/O; therefore, do not 
use EtCB to read this device. 

14. A virtual machine IPL with the NOCLEAR option renders one page of 
the virtual machine invalid. The IPL simulator uses one page of 
the virtual machine to initiate the IPL function. The starting 
address of the invalid page is either the result of the following 
formula: 

virtual machine size 

= starting address of invalid page 

2 

or the hexadecimal value 20,000, whichever is smaller. 

15. To maintain system integrity, data transfer seguences to and from a 
virtual system console are limited to a maximum of 2032 bytes. 
Channel programs containing data transfer seguences that violate 
this restriction are terminated with an interrupt whose CSW status 
indicates incorrect length and a channel program check. 

Bote: A data transfer seguence is defined as one or more read or 
write CCWs connected via chain data. The introduction of command 
chaining defines the start of a new data transfer seguence. 

16. If you intend to define more than 73 virtual devices for a single 
virtual machine, be aware that any single reguest for free storage 

■; ^ ^-^^^r^r^ ^-e CIO A^,-,UT ^tj^-r'Ae' 1^ ■«: .1 1 1 T>-> /v^\ u -i 1 1 ^ ^ 11 E- a -I- k A V M / '3 T H 

system to abnormally terminate (ABEND code PTR007) if the extra 
storage is not available on a contiguous page. Therefore, two 
contiguous pages of free storage must be available in order to log 
on a virtual machine with more than 73 virtual devices (three 
contiguous pages for a virtual machine with more than 146 virtual 
devices, etc.). Contiguous pages of free storage are sure to be 
available only immediately after IPL, before other virtual machines 
have logged on. Therefore, a virtual machine with more than 73 
devices should be the first to log on after IPL. 

17. When an I/O error occurs on a device, the System/370 hardware 
maintains a contingent connection for that device until a SENSE 
channel command is executed and sense data is recorded. That is, no 
other I/O activity can occur on the device during this time. Under 
VM/370, the contingent connection is maintained until the SENSE 
command is executed, but I/O activity from other virtual machines 
can begin on the device while the sense data is being reflected to 
the virtual machine. Therefore, the user should be aware that on a 
shared disk, the access mechanism may have moved during this time. 

18. The mode setting for 7-track tape devices is maintained by the 
control unit. Therefore, when a virtual machine issues the SET 
MODE channel command to a 7-track tape device, it changes the mode 
setting of all 7-track tape devices attached to that control unit. 
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I This has no effect on virtual machines (such as OS or DOS) that 

I issue SET MODE each tiae a CCW string is to be executed. However, 

I it can cause a problea if a virtual machine fails to issue a SET 

I node with each CCW string executed. Another virtual machine may 

I change the mode setting for another device on the same control 

I unit, thereby changing the mode setting of all 7-track tape devices 

I attached to that control unit. 

I 19. 0S/VS2 is supported in uniprocessor mode only. 

I 20. For remote 3270s, VM/370 supports a maximum of 16 binary 

I synchronous lines, minus the number of 370U/3705 Communications 

I Controllers in NCP mode minus one (if there are any 370U/3705 

I Communications Controllers in emulation mode) . 

I 21. If an I/O device (such as a disk or tape drive) drops ready status 

I while it is processing virtual I/O activity, any virtual machine 

I users performing I/O on that device are unable to continue 

I processing or to log off. Also, the LOGOFF and FORCE commands are 

I not effective because they do not complete until all outstanding 

I I/O is finished. The system operator should determine which I/O 

I device is involved and make that device ready once more. 



I CMS BESTRICTIQNS 

I The following restrictions apply to CMS, the conversational subsystem of 

I VM/370: 

I 1. CMS executes only on a virtual IBM System/370 provided by VH/370. 

I 2. The maximum sizes of CMS minidisks are as follows: 

I 5isk Maximum Cjrlinders 

I 231U/2319 203 

I 3330 Series 246 

I 3340 Model 35 349 

I 3340 Model 70 682 

i 3. Onit record eguipment cannot be dedicated to CMS; the spooling 

I facilities of VM/370 must be used. 

I 4. Only those OS facilities that are simulated by CMS can be used to 

I execute OS programs produced by language processors under CMS. 

I 5. Many types of object programs produced by CMS (and OS) languages 

I can be executed under CMS using CMS's simulation of OS supervisory 

I functions. The following functions, although supported in DOS and 

I OS virtual machines under VM/370, are not supported under CMS: 

I • The execution of DOS object programs. Although DOS programs can 

I be assembled under CMS (using the VM/370 Assembler) , DOS object 

I programs cannot execute under CMS. 

I • The writing or updating of OS data sets and DOS files. 

I 6. CMS can read sequential and partitioned OS data sets and sequential 

I DOS files, by simulating certain OS macros. 

I The following restrictions apply when CMS reads OS data sets that 

I reside on OS disks: 
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• Read-password-protected data sets are not read. 



• Multi-volume data sets are read as single-volume data sets. 
End-of -volume is treated as end-of-file and there is no 
end-of-volume switching. 

• Keys in data sets with keys are ignored and only the data is 
read. 

• User labels in user-labeled data sets are bypassed. 

The following restrictions apply when CMS reads DOS files that 
reside on DOS disks : 

• No DOS macros are simulated. 

• Only DOS sequential files can be read. CMS options and operands 
that do not apply to OS sequential data sets (such as the MEMBER 
and COHCAT options of FILEDEF and the PDS option of MOVEFILE) 
also do not apply to DOS sequential files. 

• The following types of DOS files cannot be read: 

— DOS VSAM, DAM, and ISAM files. 

— DOS core image, relocatable, source statement and procedure 
libraries. 

— Files with the input security indicator on. 

— DOS files that contain more than 16 user label and/or data 

extents. (If the file has user labels, they occupy the 

first extent; therefore the file must contain no more than 
15 data extents.) 

• Multi-volume files are read as single-volume files. 
End-of-volume is treated as end-of-file. There is no 
end-of-volume switching. 

• User labels in user-labeled files are bypassed. 

• Since DOS files do not contain BLKSIZE, RECFM, or LRECL 
parameters, these parameters must be specified via FILEDEF or 
DCB parameters, otherwise, defaults of BLOCKSIZE=32760 and 
RECFM=U are assigned. LRECL is not used for RECFM=U files. 



MISCELLANEOUS RESTRICTIONS 

If you intend to run VM/370 Release 1 and Release 2 systems alternately, 
apply Release 1 PLC 14 or higher (APAR VI 179) to your Release 1 system, 
to provide compatibility and to prevent loss of spool files in case of a 
warm start. 
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A 

abbreviations in command lines 349 

access modes 

defining for minidisks 1U5 
of CMS files 32 
accessing CMS disks 31 
ACCOUNT control statement 141 
accounting number, defining in VM/370 

directory 141 
ACCT option, defining in VH/370 directory 

143 
Acoustic Coupler feature 84 
ADAPTER operand, of RDEVICE macro 101 
ADDRESS operand 

of RCHANNEL macro 108 
of RCTLUNIT macro 106 
of RDEVICE macro 98 
address 

assigned to system residence volume 
during system generation procedure 
165, 186,208 
defining virtual device addresses for 
RSCS 229 
A-disk 26 

ALLOCATE control statement of 
Format/Allocate program 378 
allocating 

DASD space for CP use 379 
DASD space on CP-owned volumes 116 
the system residence volume 162,183,204 
3340 volumes when building 3340 system 
from current system 401 
ALTCONS operand of RIOGEN macro 110 
Alternate Character Set feature 84 
alternate console, defining 110 
alternate track assignment, IBCDASDI 372 
alternate tracks for minidisks 69 
APL 

executing in a virtual machine 42 
restricted use with Network Control 

Program (NCP) 242 
restricted use with Partitioned 
Emulation Program (PEP) 243 
application programming facilities of 

VM/370 37 
applying 

IBM-supplied updates 
example 311 
with VMFASM 287 
PTFs 

to the 3704/3705 control program 266 
to VM/370 283 
your own updates to VM/370 288 
ASM6END 

generating the Assembler 308 
responses 308 
when to use 347 
ASM3705 command 253 

files created by 254 
ASP virtual machine 47 

system generation reguirements 48 
VM/370 directory reguirements 48 



Assembler 28 

building the 3705 assembler 246 

for VM/370 335 

optional tape for system generation 160 

updating with VMFBLD 304 

using ASMGEND to generate 308 
assembling 

the CP system control file 172,193,215 

the forms control buffer 173,194,215 

the real I/O configuration file 
172,193,215 

the RSCS configuration table 330 

the standalone spool remote program 273 

the 3704/3705 macros 253 
assigning an alternate track, IBCDASDI 372 
Audible Alarm feature 83 

Automatic EOB on Carrier Return feature 83 
Automatic Ribbon Shift and Line Feed Select 

feature 83 
Automatic Turnaround feature 89 
AUX files 

definition 281 

identification records 281 
auxiliary directories 

creating for the Assembler 308 

using VMFBLD to create for EREP and the 
Assembler 304 
auxiliary files 

definition 281 

example of 287,289 
auxiliary storage, reguired by CMS 24 
available real storage. Formula 1 19 
AXSLINKS COPY file 229 

creating 229,234 

GENLINK macro 230 



B 

back up, using DASD Dump Restore program 

363 
backing up, the newly generating VM/370 

system 177,198,219 
BASE control record, ZAP program 326 
Base Expansion feature 86 
BASEADD operand, of RDEVICE macro 102 
Batch Facility 34 

adding routines 34 
EXEC procedures for 34 
VM/370 directory entries 34 
BHSET macro 246 
BMX option 37 

defining in VM/370 directory 143 
BSCGEND, when to use 347 
BUILD macro 247 
building 

a new CMS nucleus 

creating a CMS system disk 315 
example 314 

generating the CMS nucleus 315 
saving CMS 320 
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a new CP nucleus, exanple 311 

a new nucleus for CP, CMS, or RSCS 301 

a new RSCS nucleus 304,329 

creating an RSCS system disk 329 

disks needed 329 

generating the RSCS nucleus 330 
the VM/370 directory during system 

generation 172,193,214 
the 3705 assembler 246 



calculating 

available real storage 19 

maximum size of virtual=real area 20 
capacity of device when formatted 375 
card input, to Format/Allocate program 377 
chain link 31 
channel index table 110 
Channel Indirect Data Addressing feature 

75 
channel switching 49 

between two CPUs 50 

for tape 51 

on one CPU 51 

system generation requirements 50 
choices, representation in command formats 

350 
CHTYPE operand, of RCHAMNEL macro 108 
CLASS operand 

of GEMLINK macro 230 

of RDEVICE macro 99 
CLUSTER macro 246 

CMS operand, of VMFBLD command 301 
CMS, see Conversational Monitor System 

(CMS) 
CMSGEND 279 

example of use 290,321 

format 306 

generating a CMS module 306 

responses 307 

when to use 347 
COBOL, see Full American National Standard 

COBOL 
commands 

equivalent VM/370 and CP-67 commands 
384 

equivalent VM/370 and CP-67/CMS commands 
389 

functions of CMS commands 27 

notational conventions 349 

service program, DDR 354 

syntax, comparison of VM/370 and CP-67 
384 

to load the CMS nucleus 319 

ZAP 322 
comment control record, ZAP program 328 
communications system test virtual machine 

44 
COMP macro 246 

compatibility, of VM/370 and CP-67/CMS 383 
concurrent execution of virtual machines 

36 
configuration aid 337 
configuration macros for 3704/3705 251 



configuration table, assembling for RSCS 

235,330 
configurations supported by VM/370 72 
CONS operand, of RIOGEN macro 110 
CONSOLE control statement 144 
console input, to Format/Allocate program 

381 
console, defining the real system console 

110 
control card for the loader 296 
control files 281 

AUX file identification records 281 
entering comments 282 
example 287,289,309,311 
use with VMFLOAD 293 
MACS record 281 
supplied by IBM 282 
DMKR20 CNTRL 282 
DMSM20 CNTRL 282 
DMSR20 CNTRL 282 
DMTR20 CNTRL 282 
NCPR20 CNTRL 282 
update identification records 281 
update level identifier 281 
used with VMFLOAD command 292 
Control Program (CP) 13 

address where modules loaded 296 
applying IBM-supplied updates 287 
building a new nucleus with VMFBLD 301 
commands equivalent to CP-67 commands 

38 4 
compatibility with CP-67 383 
DASD space requirements 63 
disk access 31 
error recording, DASD space requirements 

64 
free storage requirements 61 
functions exercised by the IVP 224 
generating the nucleus 297 
loading the nucleus 175,195,217 
loadlist requirements 294 
macros, notational conventions 349 
minimum configuration 72 
nucleus 

DASD requirements 63 

example of building 311 

example of loading 312 

loading nucleus with virtual=real 

area 175,196,217,298 
loading nucleus without virtual=real 

area 175,196,217 
reducing the size of 63 
special VMFBLD procedure for nucleus 
with virtual=real area 303 
optional tape containing assembly 

listings 160 
paging, DASD requirements 64 
real control blocks storage requirements 

61 
real storage requirements 61 

example 62 
requirements to regenerate 347 
resident nucleus storage requirements 

61 
saved systems, DASD requirements 64 
spooling, DASD requirements 64 
system disk, example of copying 365 
system support plan 285 
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trace table storage requirements 61 

verifying 224 

VM/370 directory, DASD space 

warm start data, DASD space requirements 
64 
control statements, DDR service program 

355 
controlling the operation of the standalone 

spool remote program 275 
COKUKIT operand, of 3RF2780 macro 273 
Conversational Monitor System (CMS) 13 
A-disk 26 

applying IBM-supplied updates 287 
auxiliary storage requirements 24 
Batch Facility 34 

building a new nucleus with vMFBLD 303 
capacity of virtual disk 30 
chain link 31 

COBOL execution restrictions 28 
command language 27 
commands equivalent to CP-67/CMS 

commands 389 
compatibility with CP-67/CMS 383 
creating CMS disk-resident modules 321 
default device addressess 25 
devices supported 25 
DIRECT command 137 
disk management 29 
disk-resident modules 321 
disks 

access 31 

capacity 30 

formatting 30 

labels 29 

linking 31 
editing files 34 
example 

building a new CMS nucleus 314 

CMS BATCH 342 

virtual machine for 342 
executable Tiro'^ram Tiroducts 335 
file management 29,30 
File Status Table 31 
filemodes 32 
files sharing 32 
files 

access modes 32 

format 30 

maximum number 30 
functions exercised by the IVP 224 
generating a module 306 
generating the nucleus 297 
invoking the Directory program 137 
libraries 27 

limited support of OS and DOS 29 
loading during system generation 

169,190,211 
macros 

equivalent to CP-67/CMS macros 397 

notational conventions 349 
master file directory 30 
messages issued while nucleus is being 

generated 3 15 
minidisk labels 70 
minimum configuration 73 
modules, when to regenerate 347 



nucleus 

commands issued to load it 319 
example of building 314 
generating 315 
when it must be regenerated 347 

optional tape containing assembly 
listings 160 

planning considerations 24 

PL/I execution restrictions 28 

printing files 33 

prcgrais j.anguag6s < 

punching card files 33 

reading card files 33 

records, maximum number per file 30 

requirements to regenerate 347 

sample VM/370 directory entry 26 

saving a copy of 35 

saving during system generation 
181,202,223 

sharing the system residence volume 40 

source programs 320 

symbolic names for devices 25 

system disk 26,164,185,206 
creating 315 
moving 178,199,220 

system support plan 285 

tape support 32 

text processing 28 

unit record support 26,33 

verifying 224 

virtual storage requirements 24 
copy statement, DDR service program 357 
copying real disks, example 365 
Correspondence feature 83 
CORTABLE, defining 122 
CP operand, of VMFBLD command 301 
CP system control file 

assembling during system generation 
172,193,215 

performance considerations 115 

preparing 114 

printing and punching the starter system 
supplied copy 171,192,213 

reassembling 297 

supplied with the starter system 114 

SYSCOR macro 122 

SYSLOCS macro 125 

SYSOPR macro 121 

SYSOWN macro 116 

SYSRES macro 118 

SYSTIME macro 123 

updating and assembling when building 
3340 system from current system 404 
CP» see Control Program (CP) 
CPHAME operand 

of NAMENCP macro 155 

of RDEVICE macro 102 
CPSIZE operand, of NAMENCP macro 155 
CPT-THX 

ICA features 87 

sign-on procedure 266 

2701 required features 85 

2702 required features 86 

2703 features 86 
CPTYPE operand 

of NAMENCP macro 155 
of RDEVICE macro 101 
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CPUS 

desirable features 75 
required features 75 

for RSCS 91 
supported by VM/370 75 
CP-67, commands equivalent in VM/370 384 
CP-67/CHS 

commands equivalent in VH/370 389 
compatibility with VM/370 383 
macros equivalent in VM/370 397 
creating a 3340 system 

allocating 3340 volumes 401 

applying PLC tape 400 

changing the label of the 3340 disk 406 

copying minidisks 404 

formatting minidisks 403 

formatting 3340 volumes 401 

from a current system 399 

generating a new CMS nucleus 405 

generating a new CP nucleus 405 

labeling 3340 volumes 401 

loading 

CMS 399 

new CP macro library 399 
the new VM/370 directory 404 
updating and assembling 

CP system control file 404 
the system name table 404 
updating 

the current VM/370 directory 402 
the real I/O configuration file 400 
what you need 399 
creating an RSCS system disk 329 
current system, using to generate a 3340 

system 399 
COTYPE operand, of RCTLUNIT macro 106 
cylinder zero format, 3330 376 



D 

DADEF statement, IBCDASDI 368 
DASD Dump Restore program 354 
control statements 355 
COPY statement 357 
copying real disks 365 
copying the CMS system disk 365 
creating a standalone punch file 297 
creating a standalone version on disk 

297 
DUMP statement 357 
function statements 357 
INPUT statement 355 

invoking as a standalone program 354 
invoking under CMS 354 
I/O definition statements 355 
loading from the starter system tape 

163,184,205 
OUTPUT statement 355 
PRINT statement 359 
RESTORE statement 357 
SYSPRINT statement 357 
TYPE statement 359 
using to back up disks 363 
using to back up system residence volume 

364 
using to back up the newly generating 

VM/370 177,198,219 



using to restore starter system to disk 
163,184,205 
DASD space 

allocating for the VM/370 directory 135 

allocating on CP-owned volumes 116 

calculating cylinders needed to contain 
warm start data 120 

for CMS minidisks 65 

formatting for the VM/370 directory 135 

needed by CMS 24 

required by CP 63 

required by CP nucleus 63 

reserving for a CP nucleus with a 
virtual=real area 18 

reserving for 3704/3705 control program 
image 59 
DASD 

configuration aid for 338 

control units supported by VM/370 77 

required features 78 

restrictions 78 

supported by VM/370 77 
Data Set Attachment and Dialup feature 82 
data transmission paths, defining in your 

RSCS system 229 
DATETIME macro 246 

DDR (see DASD Dump Restore program) 
DDR command 354 
DEDICATE control statement 147 

example 147 
dedicated lines, restricted use with 

Partitioned Emulation Program (PEP) 243 
defaults, representation in command formats 

350 
defective tracks on minidisks 69 
defining 

data transmission paths for RSCS 229 

minidisks 66 

total number of tag slots for RSCS 229 

virtual device addresses for RSCS 229 
device addresses, changing for the loader 

295 
devices 

channel switching 49 

coding the RDEVICE macro for system 
console 98 

coding the RDEVICE macro for unsupported 
devices 98 

configuration aid for 337 

CPUs supported by VM/370 75 

DASD supported by VM/370 77 

default addresses for CMS 25 

defining for starter system 165,186,207 

defining the subclass for unsupported 
devices 100 

linking at logon 148 

magnetic tape supported by VM/370 79 

making available during system 
generation procedure 168,189,211 

needed for system generation 159 

real devices supported by VM/370 72 

remote spooling devices supported by 
VM/370 89 

sample configuration 111 

simulated by programming 149 

supported by CMS 25 
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terminals supported by VM/370 81 
unit record devices supported by VM/370 
80 
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machines 92 
DEVTYPE operand, of RDEVICE macro 98 
DIAGNOSE X'50' instruction 261 
DIAL command 

restricted use with Network Control 
Program (NCP) 242 

restricted use with Partitioned 
Emulation Program (PEP) 243 
DIALSET macro 246 

direct access storage device (see DASD) 
DIRECT command 137 

format 138 
DIRECT operand, of GENERATE command 299 
DIRECTORY control statement 139 
Directory program 136 

ACCOUNT control statement 141 

CONSOLE control statement 144 

control statements 138 

creating a standalone punch file 297 

creating a standalone version on disk 
297 

DEDICATE control statement 147 

DIRECTORY control statement 139 

invoking under CMS 137 

IPL control statement 143 

LINK control statement 148 

MDISK control statement 144 

OPTION control statement 141 

running standalone 138 

SPECIAL control statement 149 

SPOOL control statement 146 

USER control statement 139 
disks 

channel switching between two CPUs 50 

channel switching on one CPU 51 

CMS, access 31 

formatting for CMS 30 

labels, CMS 29 

management under CMS 29 
display devices, configuration aid for 338 
distribution code, defining in the VM/370 

directory 141 
DMKFCB (see forms control buffer) 
DMKFCB operand, of GENERATE command 299 
DMKRIO operand, of GENERATE command 299 
DMKRIO, sample file 113 
DMKR20 CNTRL 282 
DMKSNT (see system name table) 
DMKSNT operand, of GENERATE command 300 
DMKSRP (see standalone spool remote 

program) 
DMKSYS operand, of GENERATE command 299 
DMKSYS, supplied with the starter system 

114 
DMSM20 CNTRL 282 
DMSR20 CNTRL 282 
DMTLOC macro library 229 

creating 234 
DMTR20 CNTRL 282 
DOS 

Initialize Disk utility program 69 

initializing minidisks for 68 

support under CMS 29 
DUMP control records, ZAP program 324 



DUMP statement, DDR service program 357 
dumps, example of virtual machine that 
receives system dumps 341 
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EBCDIC Code feature 85 

EBCDIC feature 83 

EBCDIC Transmission Code feature 89 

EBCDIC Transparency feature 85,89 

ECMODE option 37 

defining in VM/370 directory 142 

EDIT macro 246 

editing, CMS files 34 

Editor 34 

EIA Interface with Clock feature 83 

Emulation Program (EP) 239 

see also 3704/3705 control program 
how to code the RDEVICE macro 56 
macro coding considerations 252 
special considerations for loading 263 
support under VM/370 241 

emulators, integrated emulators under 
VM/370 336 

enabling, the line for the standalone spool 
remote program 274 

END control record, ZAP program 328 

END statement, IBCDASDI 371 

ENDBH macro 246 

EP, see Emulation Program (EP) 

EREP, updating with VMFBLD 304 

error recording cylinders, defining 119 

error recording, DASD reguirements 64 

example 

applying 

IBM-supplied updates 311 
your own updates to VM/370 289 
auxiliary files 287,289 
backing up 
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system residence volume with DDR 
program 364 
building 

a new CMS nucleus 314 

a new CP nucleus 311 
control file 287,289,309,311 
copying 

real disks 365 

the CMS system disk 365 
files used to update VM/370 310 
loading an updated CP nucleus 312 
MTA macros 250 
saving CMS 320 
SRP2780 macro 273 
update files 287,289,311 
using CMSGEND 290,321 
using control file with VMFLOAD 293 
using VMFASM 

to update modules 287 

to update source files 311 
using VMFLOAD 290,292 
3704/3705 configuration macros 251 
EXEC procedure 

to help you install the standalone spool 

remote program 275 
used to regenerate CMS 347 



Index 



411 



executing VBFBLD during system generation 

procedure 170,191,212 
execution, concurrent virtual machines 36 
Expanded Capability feature 85 
Expansion feature 85 
extended floating-point feature 76 



FEATURE operand 

of RCTLONIT macro 106 
of BDEVICE macro 99 
features 
CPU 

Channel Indirect Data Addressing 75 

extended floating-point 76 

floating-point 75 

system timing facility 75 

virtual machine assist feature 75 

Word Buffer 75,76 
required by DASD 78 
RSCS 89 
TCUs 

Base Expansion 86 

EBCDIC Code 85 

EBCDIC Transparency 85 

Expanded Capability 85 

Expansion 85 

Synchronous Data Adapter Type II 85 

Telegraph Adapter Type II 85 

31 Line Expansion 86 
terminals 

Acoustic Coupler 84 

Alternate Character Set 84 

Audible Alarm 83 

Automatic EOB on Carrier Return 83 

Automatic Ribbon Shift and Line Feed 
Select 83 

Data Set Attachment and Dialup 
feature 82 

EBCDIC or Correspondence 83 

EIA Interface with Clock 83 

for the 2741 81 

Half-duplexed 83 

IBM Line Adapter 82 

Lower Case Character Display 83 

Operator Identification Card Reader 
83 

Pin Feed Platen 82 

Print Inhibit 82 

PTTC/EBCD 81 

Receive Interrupt 82 

Red Ribbon Control 82 

Transmit Interrupt 82 

Typamatic Keys 82 

1050 features 82 

1051 control unit features 82 
1200 bps Integrated Modem/Interrupt 

83 

2741 START/STOP 83 

3270 83 
Two-channel Switch 92 
2780 

Automatic Turnaround 89 

EBCDIC Transmission Code 89 

EBCDIC Transparency 89 

144 Character Print Line feature 89 



3704/3705, Multiple Terminal Access 
(MTA) 249 
file directory 30 
file management, CHS 29,30 
File Status Table 31 
fileaodes 32 
files 
CMS 

editing 34 

maximum number of records 30 
printing 33 
punching 33 
reading 33 
maximum number per CMS disk 30 
sharing in CMS 32 
floating-point feature 75 
FORMAT (CP) 69 
FORMAT control statement. Format /Allocate 

program 378 
format 

of CMS files 30 
of commands, interpreting 350 
of READ control statement 173,194,215 
of 3330 cylinders for use by CP 375 
FORMAT, use with CMS minidisks 68 
Format/Allocate program 377 
card input 377 
console input 381 

creating a standalone punch file 297 
creating a standalone version on disk 

297 
loading from starter system tape 
161, 182,203 
formatted, device capacity when 375 
formatting 

CMS disks 30 

minidisks during system generation 

178,199,221 
minidisks to contain CMS source programs 

320 
minidisks when building 3340 system from 

current system 403 
the A-disk for the standalone spool 

remote program 272 
the RSCS system disk 233 
the system residence volume 161,182,203 
volumes, general information 375 
3340 volumes when building 3340 system 
from current system 401 
forms control buffer 

assembling during system generation 

173, 194,215 
printing and punching the starter system 

supplied copy 171,192,213 
reassembling 297 

supplied with starter system 156 
Formula 1 (calculating available real 

storage) 19 
Formula 2 (calculating maximum size of 

virtual=real area) 20 
FORTRAN Interactive Debug 335 
FORTRAN IV 28 
free storage, permanently allocated for CP 

61 
Full American National Standard COBOL 28 

execution restrictions under CMS 28 
function statements, DDR service program 
357 
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GENERATE 279,297 

DIRECT operand 299 

DMKFCB operand 299 

DMKHIO operand 299 

DMKSNT operand 300 

DHKSYS operand 299 

format 298 

invoking 173,194,216 

IPLDECK operand 300 

NUCLEUS operand 300 

SRVCPGM operand 300 

using during system generation 

171, 191,213 
using to load CP nucleus 175,195,217 
virtual addresses assumed during 

processing 297 
VM370 operand 298 
when to use 348 
generating 

a CMS nucleus 297,315 

messages issued 315 
a CP nucleus 297 
a new nucleus 292 
a new RSCS nucleus 330 

assembling the configuration table 
330 

copying supervisor files to the 
system disk 330 

copying the line drivers to the 
system disk 331 

loading the RSCS files 330 
a 3340 system from a current system 399 
RSCS 

assembling the configuration table 
235 

building the RSCS nucleus 235 

creating the COPY files that define 
your RSCS system 233 

creating the DMTLOC macro library 
234 

formatting the RSCS system disk 233 

loading 236 

loading CMS 232 

loading the PLC tape 232 
the 3704/3705 control program 237,244 

applying PTFs 266 

ASM3705 command 253 

assembling the 3705 source files 257 

building the text library 257 

building the 3705 assembler 246 

coding the BUILD macro 247 

coding the HOST macro 249 

coding the macros 246 

coding the SYSCNTRL macro 248 

configuration macros 251 

defining the macro and text libraries 
252 

defining the necessary files 257 

GEN3705 command 255 

GROUP macro 251 

link editing the 3705 text files 257 

LKED command 258 

LOADCC EXEC file 245 

loading it 262 

loading the program from tape 245 

logging on 244,264 

required macro libraries 246 



required text libraries 246 

SAVENCP command 261 

saving it 260 

setting up the CMS virtual machine 

244 
Stage 1 252 
Stage 2 255 
3340 system residence volume from a 
current system 15 
GENLINE macro 
format 231 
LINE operand 231 
GENLINK macro 47 

CLASS operand 230 
format 230 
ID operand 230 
KEEP operand 230 
LINE operand 230 
requirements for coding 230 
TASK operand 230 
TYPE operand 230 
GENTAGQ macro 
format 231 
NUM operand 231 
GEN3705 command 255 
file created 256 
GETALT statement, IBCDASDI 373 
graphic devices, eliminating support for 

63 
GROUP macro 251 



H 

Half-duplexed feature 83 

hardware service, example of virtual 

machine for 342 
hardware support, virtual machines 127 
HOST macro 249 



IBCDASDI 

assigning alternate tracks for minidisks 
69 

creating a standalone punch file 297 

DADEF statement 368 

END statement 371 

general information 366 

GETALT statement 373 

invoking 374 

IPLTXT statement 371 

JOB statement 368 

LASTCARD statement 371 

MSG statement 368 

restrictions 366 

statements 367 

use with OS and DOS minidisks 68 

VLD statement 370 

VTOCD statement 370 
IBM Line Adapter feature 82 
IBM program numbers, for program products 

335 
IBM program products 

executable under CMS 335 

IBM program numbers 335 

integrated emulators 336 
ICA (see Integrated Communications 
Attachment) 
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ID operand 

of GENLIHK macro 230 
of SYSTIME macro 124 
lEHDASDI 69 
lEHDASDR 69 
initialization 

with surface analysis 366 
without surface analysis 367 
initializing a minidisk 366 
INPP (DOS Initialize Disk utility program) 

69 
input control records, ZftP 323 
INPUT statement, DDR service program 355 
input 

card, to Format/Allocate program 377 
console, to Format/Allocate program 381 
Installation Verification Procedure (IVP) 
15,22U 

CMS functions tested 224 
CP functions tested 224 
executing 

in a single virtual machine 226 
with virtual machines other than 

IVPM1 and IVPM2 226 
without testing system abnormal 
termination processing 226 
interpreting, the results 227 
starting it 225 

virtual machine reguirements 224 
Installed User Programs (lUPs) 
MUSIC 335 
SCRIPT/370 335 
supported by VM/370 335 
installing 

CP and CMS 14 
R SC S 15 

the standalone spool remote program 
(DMKSRP) 272 
Integrated Communications Attachment, 

features 87 
interactive virtual machines 36 
internal pointers, generating 125 
interpreting the results of IVP processing 

227 
interruption codes, for the loader 296 
introduction, to the 3704/3705 control 

program 239 
invoking 

DDR as a standalone program 354 

DDR under CMS 354 

IBCDASDI 374 

the GENERATE EXEC procedure 173,194,216 

VMFBLD 

during RSCS system generation 232 
to build the RSCS nucleus 235 
I/O definition statements, DDR service 

program 355 
I/O waits in a virtual machine 39 
lOLIST macro 246 
IPL control statement 143 

IPL, CP nucleus with virtual=real area 19 
IPLDECK operand, of GENERATE command 300 
IPLTXT statement, IBCDASDI 371 
IPLUNIT operand, of SPR2780 macro 272 
ISAM option 37 

defining in VM/370 directory 142 
ISAM, channel programs 38 



JOB statement, IBCDASDI 368 



KEEP operand, of GENLINK macro 230 



LABEL function, Format/Allocate program 

380 
label 

CMS disk labels 29 

for minidisks 69 

of starter system volume 163,184,205 
labeling 

DASD volumes 380 

the starter system volume 163,183,205 

the system residence volume 162,183,204 

3340 volumes when building 3340 system 
from current system 401 
LASTCARD Statement, IBCDASDI 371 
LAXLINES COPY file 229 

creating 231,234 

GENLINE macro 231 
libraries, macro libraries for CMS 27 
LINE macro 251 
LINE operand 

of GENLINE macro 231 

of GENLINK macro 230 
LINELIST macro 246 
LINK command 31 

sharing minidisks 70 
LINK control statement 148 
link editing the 3705 files 258 
link, definition 229 

linkage editor control statements 258 
linking, CMS disks 31 
LKED command 258 

files created 259 

LOADCC 

loading the 3704/3705 control program 
from tape 245 

when to use 348 
loader 295 

changing device addresses 295 

interruption codes 296 

load map 296 

set page boundary (SPB) control cards 
294 

wait conditions 295 
loading 

newly generated VM/370 system 
176, 197,218 

the standalone spool remote program 274 

the 3704/3705 control program 262 
loadlist 

file 292 

for CP nucleus with virtual=real area 
293 

for CP nucleus without virtual=real area 
293 

pageable modules for CP 29i» 

reguirements for CP 294 
LOC operand, of SYSTIME macro 123 
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locked pages 45 

logging on 

after NCP abnormal termination 266 
through lines controlled by the 
370U/3705 control program" 264 

logical records, CMS 30 

Lower Case Character Display feature 83 



H 

macro libraries 

creating the DMTLOC macro library for 
RSCS 234 

defining for 3704/3705 system generation 
252 

generating for RSCS 229 

SCPMAC01 246 

NCPMAC02 246 

required to generate the 3704/3705 
control program 246 

updating with VMFMAC 291 

used to create 3340 system from a 
current system 399 
macros 

BHSET 246 

BUILD 247 

CLUSTER 246 

COUP 246 

DATETIME 246 

DIALSET 246 

EDIT 246 

ENDBH 246 

equivalent VM/370 and CP-67/CMS macros 
397 

GENLIHE 231 

GENLINK 47 

GENTAGQ 231 

GROUP 251 

HOST 249 

lOLIST 246 

LINE 251 

LIHKLIST 246 

MTALCST 249 

MTALIST 249 

MTATABL 249 

NAMENCP 155 

NAMESYS 153 

notational conventions 349 

OS macro libraries under CMS 27 

RCHANNEL 108 

RCTLUNIT 106 

RDEVICE, to support 3704/3705 control 
program 54 

RIOGEN 110 

SERVICE 246 

simulation of OS macros under CMS 29 

SRP2780 272 

STARTBH 246 

SYSCNTRL 248 

SYSCOR 122 

SYSLOCS 125 

SYSOPR 121 

SYSOHN 116 

SYSRES 118 

SYSTIME 123 

TERMINAL 251 

TSO macro libraries under CMS 27 

UBHR 246 



MACS record, of control files 281 
magnetic tape 

control units supported by VM/370 79 

devices supported by VM/370 79 
master file directory 30 
MAXDIAL operand, of RDEVICE macro 102 
maximum size of virtual=real area 20 
MDISK control statement 144 

example 146 
MDISK statements, sharing minidisks 70 
messages- issued while CMS nucleus is being 

generated 315 
minidisks 66 

see also virtual disks 

backing up with DASD Dump Restore 
program 363 

r^Qnyin*^ when buildin'^ 3340 system from 
current system 404 

defining 

in VM/370 directory 144 
primary access mode 145 

example of use and definition 67 

formatting during system generation 
178,199,221 

initializing 366 

for OS and DOS 68 

labels 69 

linking to 70 

MDISK control statement 70 

multi-write access of 71 

overlapping extents 127 

passwords for 71 

permanent 66 

read-only access of 71 

read/write access of 71 

sharing among virtual machines 70 

temporary 66 

track characteristics 68 
minimum configuration 

for CMS 73 

for RSCS 73 

for VM/370 72 
minimum truncations in command lines 349 
MNOTE messages 

for RCHANNEL macro 109 

for RCTLUNIT macro 107 

for SYSCOR macro 122 

for SYSOWN macro 117 

for SYSRES macro 120 

for SYSTIME macro 124 

for the RDEVICE macro 102 
model numbers, of the 3704/3705 55 
MODEL operand, of RDEVICE macro 99 
modules 

CP, address where loaded 296 

creating disk-resident CMS modules 321 

generating a CMS module 306 

updating with VMFASM 286 

when to regenerate for CMS 347 
moving, the CMS system disk 178,199,220 
MSG statement, IBCDASDI 368 
MTALCST macro 249 
MTALIST macro 249 
MTATABL macro 249 
Multiple Terminal Access (MTA) feature 249 

sign-on procedure 265 
multiple virtual machines using the same 
operating system 39 
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multiple-access virtual machines UO 
communications system test 44 
performance considerations 45 
virtual transmission control units 45 
multiprogramming operating systems under 

VM/370 38 
multi-write access of minidisks 71 
MDSIC (McGill University System for 
Interactive Computing) 335 



N 

NAME control record, ZAP program 325 

MAMENCP macro 

CPNAME operand 155 

CPSIZE operand 155 

CPTYPE operand 155 

format 155 

SYSPGCT operand 155 

SYSSTRT operand 155 

SYSVOL operand 155 
NAMESYS macro 

example 154 

format 153 

SYSCYL operand 153 

SYSHRSG operand 154 

SYSNAME operand 153 

SYSPGCT operand 154 

SYSPGNM operand 154 

SYSSIZE operand 153 

SYSSTRT operand 153 

SYSVOL operand 153 

VSYSADR operand 153 

VSYSRES operand 153 
NCP, see Network Control Program (NCP) 
NCPDUMP service program 267 
NCPMAC01 macro library 246 
NCPMAC02 macro library 246 
NCPR20 CNTRL 282 
Network Control Program (NCP) 239 

see also 3704/3705 control program 

how to code, the RDEVICE macro 56 

logging on after abnormal termination 
266 

sign-on procedure 265 

special considerations for loading 263 

support under VM/370 242 
NETWORK LOAD command 262 

execution of 262 
NUCLEUS operand, of GENERATE command 300 
nucleus 

building the RSCS nucleus 235 

CMS 

building a new one 314 

generating 297 

when it must be regenerated 347 

CP 

DASD reguirements 63 
example of building 311 
generating 297 
loading 175,195,217 
loading one with virtual=real area 
298 

end of resident nucleus address 296 

generating 292 

real storage reguirements for CP 61 

reducing the size for CP 63 



RSCS 

building 304,329 

generating 330 
NUM operand, of GENTAGQ macro 231 
numbers, of IBM program products 335 



OBJ3705 text library 246 

online message, logging on 3704/3705 lines 

264 
operating systems 

core-image copy saved on disk 60 
multiprogramming under VM/370 38 
naming 153 
options 
BMX 37 
ECMODE 37 
ISAM 37 
REALTIMER 37 
performance guidelines 16 
planning considerations 36 
restrictions for executing under VM/370 

36 
sharing the system residence volume 39 
spooling considerations 39 
that execute under VM/370 14 
using reserve/release 52 
virtual machine assist feature 23 
operations facilities of VM/370 37 
Operator Identification Card Reader feature 

83 
operator, example of VM/370 directory entry 

341 
OPTION control statement 141 
options, for virtual machines 37 
OS COBOL Interactive Debug 335 
OS Code & Go FORTRAN 335 
OS FORTRAN IV (Gl) 335 
OS FORTRAN IV (H) Extended 335 
OS FORTRAN Library (Mod II) 335 
OS FORTRAN OV Library (Mod I) 335 
OS Full American National Standard COBOL 

Version 4 Library 335 
OS PL/I Checkout Compiler 335 
OS PL/I Optimizing Compiler 335 
OS PL/I Optimizing Compiler and Libraries 

335 
OS PL/I Resident Library 335 
OS PL/I Transient Library 335 
OS 

initializing minidisks for 68 
ISAM channel programs 38 
macro libraries for CMS 27 
support under CMS 29 
OS/VS COBOL Compiler and Library 335 
OS/VS COBOL Library Only 335 
output spooling classes, defining with the 

RDEVICE macro 100 
OUTPUT statement, DDR service program 355 
overlapping extents on minidisks 127 



PAGE operand, of SYSOWN macro 117 
page waits, in a virtual machine 3< 
pageable modules for CP 294 
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paging 

DASD requireaents 64 

performance considerations 115 
Fartxtioned Eioula'txon Frograiu (PEP) 239 

see also 3704/3705 control program 

how to code, the RDEVICE macro 57 

macro coding considerations 252 

sign-on procedure for lines in NCP mode 
265 

special considerations for loading 263 

support under VM/370 242 
passwords, for minidisks 71 
PEP, see Partitioned Emulation Program 

(PEP) 
performance guidelines 16 

for heavy I/O production 115 

for installation with large number of 
CMS users 115 

for I/O waits 39 

for multiple-access virtual machines 45 

for page waits 38 

for read-only minidisks 115 

multiprogramming systems 39 

virtual machine assist feature 23 

when coding the DMKSYS macros 115 
physical records, CMS 30 
Pin Feed Platen feature 82 
planning considerations 

for a virtual=real machine 17 

for CMS 24 

for supporting 3704/3705 53 

for the 3704/3705 control program 240 

operating systems other than CMS 36 

RSCS 46 
Planning Systems Generator/CMS 335 
planning, for system generation 11 
PLC tape 

applying to CMS during system generation 
179,200,222 

applying while building a 3340 system 
400 

loading during RSCS generation procedure 
232 

loading during system generation 
169, 190,212 

RSCS contents 228 

used to install RSCS 228 
PL/I 28 

execution restrictions under CMS 28 
Print Inhibit feature 82 
PRINT statement 

DDR service program 359 
sample output 362 
printing, files in CMS 33 
program languages, available with CMS 28 
programmable terminals, required features 

for RSCS 90 
programming 

application 37 

facilities of VM/370 36 
programs, service, VM/370 353 
PRTRDR operand, of SRP2780 macro 273 
PRTUNIT operand, of SRP2780 macro 273 
PTFs 

applying to the 3704/3705 control 
program 266 

applying to VM/370 283 
PTTC/EBCD feature 81 
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punching 

card files in CM 
service programs 
Deration 171 
DMKSRP TEXT 
starter syst 
ntrol file 1 
starter syst 
ntrol buffer 

starter syst 

ble 171,192, 

starter syst 

rectory 171, 

operand, of 



S 33 

during system 
,191,213 
file 274 

em supplied CP system 
71,192,213 
em supplied forms 

171,192,213 
em supplied system name 
213 

em supplied VM/370 
192,213 
SRP2780 macro 273 
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108 
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R 

RCHANNEL macro 

ADDRESS operand 

CHTYPE operand 

example 108 

format 108 

MNOTE messages 
RCHBLOK 

see also real control blocks 

creating 108 

label 108 
RCTLUNIT macro 

ADDRESS operand 106 

configuration aid for 337 

CUTYPE operand 106 

example 107 

FEATURE operand 106 

FEATDRE=xxx-DEVICE operand 105 

format 106 

MNOTE messages 107 
RCUBLOK 

see also real control blocks 

addressing 105 

creating 105 

label 105 
RDEVBLOK 

see also real control blocks 

creating 97 

label 97 
RDEVICE macro 

ADAPTER operand 101 

ADDRESS operand 98 

BASEADD operand 102 

CLASS operand 99 

coding 

for system console 98 
for unsupported devices 98 
to support the 3704/3705 control 
program 54 

configuration aid for 337 

CPNAME operand 102 

CPTYPE operand 101 

defining 

output spooling classes 100 
subclass for unsupported devices 100 

DEVTYPE operand 98 

example 102 

3704/3705 58 

FEATURE operand 99 

format 97 
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how to code 

to support the EP 370U/3705 control 

program 56 
to support the NCP 3704/3705 control 

program 56 
to support the PEP 3704/3705 control 
program 57 
MAXDIAL operand 102 
HNOTE messages 102 
MODEL operand 99 
SETADDR operand 101 
summary of coding considerations for 

3704/3705 control program 57 
unit record error messages 103 
3704/3705 error messages 103 
READ control statement, format of 

173, 194,215 
reading, card files in CMS 33 
read-only access of minidisks 71 
read/write access of minidisks 71 
real configuration, sample 111 
real control blocks 
defining 95 

real storage reguirements 61 
real control units 

DASD control units supported by VM/370 

77 
magnetic tape control units supported by 

VM/370 79 
unit record control units supported by 

VM/370 80 
3270 control units supported by VM/370 
83 
real devices 

coding the RDEVICE macro 

for the system console 98 
for unsupported devices 98 
configuring 337 
CPUs supported by VM/370 75 
DASD supported by VM/370 77 
dedicating to virtual machines 147 
magnetic tape supported by VM/370 79 
needed for system generation 159 
remote spooling devices supported by 

VM/370 89 
restriction for system console during 

system generation 161,182,203 
sample configuration 111 
supported by VM/370 72 
supported only in virtual machines 92 
terminals supported by VM/370 81 
unit record devices supported by VM/370 
80 
real I/O configuration file 

assembling during system generation 

172,193,215 
example of VM/370 system 111 
preparing 96 
RCHANNEL macro 108 
RCTLUNIT macro 105 
RDEVICE macro 97 
reassembling 297 
RIOGEN macro 110 

updating, when creating a 3340 system 
from a current system 400 



real storage 

calculating maximum size virtual=real 

area 19 
reguirements for VM/370 6 1 
REALTIMER option 37 

defining in VM/370 directory 141 
Receive Interrupt feature 82 
records, maximum number per CMS file 30 
Red Ribbon Control feature 82 
regenerating 

CMS modules 347 
service programs 348 
Remote Spooling Communications Subsystem 
(RSCS) 13 
applying IBM-supplied updates 287 
assembling the configuration table 330 
building a new nucleus 304,329 
configuration table 229 

assembling 235 
copying 

line drivers to the system disk 331 
supervisor files to the system disk 
330 
CPU reguired features 91 
creating the COPY files that define it 

233 
defining 

all data transmission paths 229 

an RSCS virtual machine 229 

more than one RSCS virtual machine 

47 
total number of tag slots 229 
virtual device addresses 229,231 
disks needed to build a new nucleus 329 
distributed on PLC tape 228 
example of use 46 

example of virtual machine for 342 
generating and installing 228 
generating the macro library 229 
generation procedure 231 

assembling the configuration table 

235 
creating the DMTLOC macro library 

234 
defining your system 229 
formatting the RSCS system disk 233 
loading CMS 232 
loading RSCS 236 
loading the PLC tape 232 
link 

defining 229 
definition 229 
loading the files on disk 304 
macros, notational conventions 349 
minimum configuration 73 
nucleus 

building 235 
generating 330 
planning considerations 46 
programmable terminals reguired features 

90 
reguired features 89 
sample VM/370 directory entry 229 
system disk 

copying line drivers to 331 
copying supervisor files to 330 
creating 329 
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system support plan 285 

virtual machine requirements 229 

what you need before you generate RSCS 

232 
2770 required features 89 
2780 required features 90 
3770 required features 90 
3780 required features 90 
REMUNIT operand, of SRP2780 macro 273 
REP control record, ZAP program 328 
requirements 

for changing the VM/370 directory 137 
RSCS, to run multiple concurrent RSCS 

virtual machines 229 
to regenerate CP and CMS 347 
reserved pages 46 
reserve ^re lease 52 

resident nucleus, ending address 296 
resource ID, recording at end of Stage 1 

255 
RESTORE Statement, DDR service program 357 
restoring, starter system to disk 

163,184,205 
restrictions 

for operating systems under VM/370 36 
IBCDASDI 366 

Network Control Program (NCP) 
DIAL command 242 
sign-on procedure 242 
TERMINAL APL command 242 
Partitioned Emulation Program (PEP) 
dedicated lines 243 
DIAL command 243 
TERMINAL APL command 243 
RIOGEN macro 

ALTCONS operand 110 
CONS operand 110 
example 110 
format 110 
RMSIZE operand, of SYSCOR macro 122 
RSCS operand, of VMFBLD command 301 



saved systems 60 

CMS 35 

DASD requirements 64 

defining 153 

saving CMS 320 

saving CMS during system generation 
181,202,223 

3704/3705 control program 260 
SAVENCP command 261 
SAVENCP command 261 

execution of 261 
SCRIPT/370 28,335 
SERVICE macro 246 
service programs 322 

creating a standalone punch file 297 

creating a standalone version on disk 
297 

Directory program 136 

loader 295 

NCPDUMP 267 

punching during system generation 
171, 191,213 

updating 280 



VM/370 353 

DASD Dump Restore (DDR) 354 
FORMAT 377 
when they must be regenerated 348 
ZAP 322 
set page boundary (SPB) control cards 

294,296 
SETADDR operand, of RDEVICE macro 101 
sign-on procedure for 3704/3705 lines in 

NCP mode 242,265 
software support, virtual machines 128 
source files, updating 311 
special considerations 

for loading the 3704/3705 control 

program 262 
for user with only one tape drive 
173, 194,215 
SPECIAL control statement 149 
SPOOL control statement 146 
spooling classes, defining with the RDEVICE 

macro 100 
spooling 

considerations 39 
DASD requirements 64 
defining virtual devices for 146 
performance considerations 115 
SRP2780 macro 272 

CONUNIT operand 273 
example 273 
IPLUNIT operand 272 
PRTRDR operand 273 
PRTUNIT operand 273 
PUNRDR operand 273 
PUNONIT operand 273 
REMUNIT operand 273 
SRVCPGM operand, of GENERATE command 300 
Stage 1 generation procedure for 3704/3705 
252 

recording resource IDs at end 255 
Stage 2 generation procedure for 3704/3705 
255 

special considerations 257 
standalone spool remote program 269 
controlling the operation of 275 
enabling the line 274 
installing 272 

assembling with VMFASM 273 
creating the DMKSRP ASSEMBLE file 

272 
enabling the line 274 
EXEC procedure to aid you 275 
formatting the A-disk 272 
loading the program 274 
logging on the 2780 virtual machine 

273 
punching the DMKSRP TEXT file 274 
introduction 271 
loading 274 
SRP2780 macro 272 
testing 275 
STARTBH macro 246 
starter system volume 

contents of restored disk 164,185,206 
format after system generation 

177,198,219 
format of 2314 restored disk 164 
format of 3330 restored disk 185 
format of 3340 restored disk 206 
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IPL of 165, 186,207 

labeling 163,183,205 

required label 163,181,205 
starter system 

see also 2314 starter system 

see also 3330 starter system 

see also 3340 starter system 

defining devices for 165,186,207 
starting the IVP 225 
statements, IBCDASDI 367 
storage, for each model of the 3704/3705 

55 
support packages, for the 3704/3705 control 

program 240 
SVCOFF option, defining in VM/370 directory 

143 
symbolic names for CMS devices 25 
Synchronous Data Adapter Type II feature 

85 
SYSCNTRL macro 248 
SYSCOR macro 

example 122 

format 122 

MNOTE messages 122 

RMSIZE operand 122 
SYSCYL operand, of NAMESYS macro 
SYSDUMP operand, of SYSOPR macro 
SYSERR operand, of SYSRES macro 1 
SYSHRSG operand, of NAMESYS macro 
SYSLOCS macro 

example 125 

format 125 
SYSNAME operand, of NAMESYS macro 
SYSNUC operand, of SYSRES macro 1 
SYSOPER operand, of SYSOPR macro 
SYSOPR macro 

example 121 

format 121 

SYSDUMP operand 

SYSOPER operand 
SYSOWN macro 

example 117 

format 116 

MNOTE messages 

PAGE operand 117 

TEMP operand 117 

volid operand 117 
SYSPGCT operand 

of NAMENCP macro 155 

of NAMESYS macro 154 
SYSPGNM operand, of NAMESYS macro 154 
SYSPRINT statement, DDR service program 

357 
SYSRES macro 

example 120 

format 118 

MNOTE messages 120 

special coding considerations 118 

SYSERR operand 119 

SYSNUC operand 118 

SYSRES operand 118 

SYSTYPE operand 118 

SYSVOL operand 118 

SYSWRM operand 119 
SYSRES operand, of SYSRES macro 118 
SYSSIZE operand, of NAMESYS macro 153 



153 
121 
19 
154 



153 
18 
121 



121 
121 
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SYSSTRT operand 

of NAMENCP macro 155 
of NAMESYS macro 153 
system abnormal termination, testing with 

the IVP 225 
system console 

coding the RDEVICE macro for 98 
configuration aid for 337 
defining 110 

restriction during system generation 
161, 182,203 
system disk 26,29 

creating for CMS 315 
creating for RSCS 329 
example of copying 365 
system generation 159 

applying PLC changes to CMS 179,200,222 
assembling the CP system control file 

172,193,215 
assembling the forms control buffer 

173,194,215 
assembling the real I/O configuration 

file 172,193,215 
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341 
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174, 195,216 
hardware support 127 
interactive execution 36 
I/O waits 39 
ISAM option 142 
linking devices at logon 148 
maximum number of devices 127 
multiple-access 40 

multiprogramming operating systems 38 
naming systems 153 
operating systems 13 
options 37 

BMX 37 

ECMODE 37 

ISAM 37 

locked pages 45 
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2780 virtual machine 274 
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